On Thursday, 15 September 2016 11:51:31 CEST Benjamin Kaduk wrote: > On 09/14/2016 02:02 PM, Andrei Popov wrote: > > Basically, I don't feel strongly about the switch to the proposed version > > negotiation mechanism. But if we are going to make this change based on > > the theory of having only one extension point and actively defending it, > > then we should probably follow the theory and send a separate TLS > > extension per TLS version. > To me, the (ordered) list of client supported versions in a single > extension feels more intuitively natural, so I want to try harder to > understand the reasoning that leads you to prefer a separate extension > for each version. Is it just that doing an additional "negotiation" > within the extension body constitutes another extension point that we > would have to actively defend, or is there something else about what a > TLS extension is philosophically supposed to indicate?
the extensions joint is well greased and works the lists inside extensions are a hit and miss, they mostly work, but then we have SNI in general, signature methods in past NSS versions, and if you dug more I wouldn't be surprised if you found half a dozen other issues just like it (in late October I may have actual numbers about it) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
