FWIW, this requirement is actually very old, dating back to RFC 3546. It's not unique to TLS 1.2.
Note that for all extension types (including those defined in future), the extension type MUST NOT appear in the extended server hello unless the same extension type appeared in the corresponding client hello. Thus clients MUST abort the handshake if they receive an extension type in the extended server hello that they did not request in the associated (extended) client hello. https://tools.ietf.org/html/rfc3546#section-2.3 -Ekr On Thu, Mar 16, 2017 at 6:47 PM, Martin Thomson <martin.thom...@gmail.com> wrote: > On 17 March 2017 at 11:22, Peter Gutmann <pgut...@cs.auckland.ac.nz> > wrote: > > Is that from actually trying it with clients, or just assuming that > > implementations will do what the spec says? > > I know for certain that NSS explodes. Not from trying, but from > knowing that part of the code very well. I'm fairly certain that > boringSSL does too, knowing David. > > You say negative utility, but I've found that if you can get away with > stricter policing of these things, it helps prevent servers from > starting to do the wrong thing. The odds that someone tests a new > server implementation against major browsers is fairly good. > > In any case, what would you expect a client to do if they don't > advertise the extension? In this case, max_fragment_length is so > badly designed that you can actually argue that it has utility, but I > don't consider that as a good argument for the general case. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
