On Sat, Mar 30, 2019, at 06:05, John Mattsson wrote: > And one more.... > > "The 0xTBD flag can only be send in a ClientHello or CertificateRequest > message. Endpoints that receive a value of 1 in any other handshake > message MUST generate a fatal illegal_parameter alert." > > This goes against draft-nir-tls-tlsflags > > "A server that supports this extension and also supports at least one > of the flag-type features that use this extension and that were > declared by the ClientHello extension SHALL send this extension with > the intersection of the flags it supports with the flags declared by > the client." > > I assume the sic sic extension should be sent in EncryptedExtensions.
I think that this is a problem in draft-nir-tls-tlsflags. Extensions in ClientHello are "answered" in two places: EncryptedExtensions and Certificate. The requirement that the flag be echoed creates a problem in that context. We could define separate "Handshake flags" and "Certificate flags", but that complicates things. If you look at extension usage, you see that not all "flags" are echoed. In this case, a requirement to echo would just increase the size of Certificate for no good reason - the extension can be omitted completely. We should only require the presence of the flag where it carries semantics. The requirement should be stated as Implementations MUST NOT set flags in extension responses if the remote endpoint did not send the corresponding flag in extension requests. Upon receiving a flag that is incorrectly set, an endpoint MUST abort the handshake with an "unsupported_extension" [?] alert. Mirroring the language from RFC 8446. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
