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.
In the past, Chrome has both steam-rollered over intolerance issues and used "naming and shaming" when it appeared useful. Naming and shaming can be an effective strategy when there is a small percentage of aberrant actors, but that doesn't appear to be the case here. It's not a single vendor, it's several, and we likely don't have a complete list because it's very difficult to get vendor/model/version information from the field. These issues vary across devices, across firmware versions (for which the active range is large), and across configurations (similarly large). As for the steam-roller: while /we/ may understand the issues in sufficient depth to know where the fault lies, the operating heuristic in IT is that the last thing that changed is to blame. That makes steam-rollering expensive. Sometimes we do it anyway, but the levels of breakage measured for the current TLS 1.3 wire-format are too high to be viable. There would have to be a fallback, and fallbacks are terrible. We've only recently gotten out of the last lot of them and should not do that again. I understand the share the justifiable anger at companies that are making profits by handicapping the internet that they depend on; we are paying their externalities right now. But the problem here is too widespread for either of the above strategies to be effective. 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. This looks, overwhelmingly, like the best path for TLS 1.3. For the future, I think we need to ponder changes in the way that we build and defend protocols. I think that GREASE (https://tools.ietf.org/html/draft-ietf-tls-grease-00) demonstrates the sort of change in thinking that is needed, but that we need to go further. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
