> On Feb 3, 2022, at 9:49 AM, Jens Guballa <j...@guballa.de> wrote: > > > > Am 03.02.22 um 17:46 schrieb Sean Turner: >>> On Feb 2, 2022, at 21:08, Christopher Wood <c...@heapingbits.net> >>> wrote: >>> >>> Hi Jens, >>> >>> >>>> On Jan 28, 2022, at 9:14 AM, Jens Guballa <j...@guballa.de> >>>> wrote: >>>> >>>> Am 27.01.22 um 17:35 schrieb Christopher Wood: >>>> >>>>> In preparing to move draft-ietf-tls-flags and >>>>> draft-ietf-tls-cross-sni-resumption forward in the process, I’m curious >>>>> if anyone is aware of implementations of either specification. If you >>>>> know of an implementation, can you please share it here? >>>>> >>>>> >>>> I am not sure what your intention is. In case you are looking for a >>>> counterpart to test a server implementation, you can have a look at >>>> https://gitlab.com/guballa/tlsmate >>>> . With that tool you can create and execute arbitrary TLS handshake >>>> scenarios against TLS servers. The TLS-flags extension is not supported >>>> (yet), but setting up (or checking) any extension as a bytestring is >>>> possible. Basic python knowledge is required, though. >>>> >>> Thanks for sharing tlsmate! >>> >>> To clarify the original request, we are asking about _existing_ >>> implementations of draft-ietf-tls-flags or >>> draft-ietf-tls-cross-sni-resumption. While one could implement either using >>> tlsmate, that has not yet been done (as you point out). >>> >> When the chairs shift the I-Ds out of the WG to the AD (Area Director) [0], >> we also need to submit a write-up [0] that our AD and the rest of the IESG >> will review. One of the questions is whether there are existing >> implementations. > Thanks for the clarification. Is there a value reserved for the tls-flags > extension? I couldn't find one, neither in the draft nor in the IANA registry.
Nope, not yet. We still need to get a codepoint for the extension. We can probably do that now. =) Best, Chris _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls