Friday afternoon seems like a tolerable time to do something so questionably productive as mailing to this thread...
On 10/25/2017 09:50 AM, David A. Cooper wrote: > This question is based on your that belief that this protocol will > "escape" onto the public Internet, that browsers and other clients > used by individuals will feel forced to implement it, and that clients > will then be forced to enable the extension in order to get through > middleboxes that would filter traffic based on whether or not the > extension is present in the ClientHello. I've already explained why I > believe that scenario will never happen, and so no I do not agree that > it is a "fundamental change." Not picking on David in particular, it just happened to be the first message I found going back through the thread that exhibited this phenomenon. Namely, I have seen a lot of reasoning along the lines of "this would never happen on the public internet because there are so many other, cheaper/more efficient/easier ways to do it". I don't find that line of reasoning very persuasive. This is not necessarily because I disagree with the cheaper/more efficient/easier classification, but rather because it seems out of scope for us as a technology organization. IMO, we ought to be considering all the potential ramifications of a protocol change, in all the environments where that protocol is or might be deployed, as a purely technological matter, so that we can understand its potential impacts. Just because something is expensive or inefficient today does not mean that it is not a capability of the technology we are developing, and cost and efficiency can change over time. In cryptanalysis, we do not discount attacks that require large amounts of storage, because they are still valid algorithmic attacks, and lo and behold, as storage gets cheaper, we find that these sorts of attacks do get used. Similarly for protocol design/analysis, we should not discount a particular protocol interaction just because there are at present other ways to do a similar thing, and those other ways currently seem more attractive. -Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
