On Sat, Oct 07, 2017 at 09:38:24AM -0700, Adam Langley wrote: > On Sat, Oct 7, 2017 at 12:17 AM, Hanno Böck <ha...@hboeck.de> wrote: > > Alternative proposal: > > > > 1. Identify the responsible vendors. > > 2. Tell all those vendors "You have 1 month to fix this. Fix it. Oh, > > it's your customers who don't update? Seems you don't have any > > reasonable update system. Call your customers, send some support staff > > to them. Fix this. Now." > > 3. Call for a boycott of the vendors who are not able to fix this.
> We're still testing, but it appears that a few, > security-inconsequential changes to TLS 1.3 make it significantly more > viable to deploy. That has got to be preferable to behaviours like > fallback, which is very security-consequential. This has taken time > because getting good exposure needs changes to both our frontends and > to Chrome Stable, which makes the iteration time long. We can iterate > much faster with local middleboxes (and we've bought several), but the > diversity of firmware versions and configurations means that we can't > get great testing coverage from that approach. Yes, and with local testing, one can't get the relative importances right, only to guide what to test on field. And even in field tests, there is issue of survivorship bias. I think that is the cause for seeming conflicts between the results. And even if the changes might not be directly consequential to security, the changes to get through some more annoying middleboxes might be quite annoying to implement. E.g. there probably are several different middeboxes that have a configuration that actually checks that the handshake looks valid, which includes checks for things like ChangeCipherSpec being present in both directions, even for resumption; while the non- resumption mode might even verify the authentication signatures in the handshake and not letting server send non-handshake messages before sending its 2nd flight. Ugh, getting around those would be pretty nasty. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
