On Wed, Sep 14, 2016 at 11:46 AM Benjamin Kaduk <bka...@akamai.com> wrote:
> On 09/14/2016 04:56 AM, Hubert Kario wrote: > > First, I don't think that the argument that the current version scheme doesn't > lend itself to future-proofing is correct. Just as with GREASE, browsers can > send much higher version than they really support if they do that on a time > limited basis. > > > David had previously convinced me that it doesn't actually work very well, > but I forget the reasoning he used to do so. :( > Right, this was suggested at Berlin but is not very realistic. First it requires that clients do so with very careful precautions (time-limited, server-side field trials, etc.). There cannot be fake-TLS-1.4 clients by the time real-TLS-1.4 is to exist. If enough implementations mess up, we lose. With a list, any library can freely implement this without depending on extra infrastructure. Second, even if we were to advertise TLS 1.4 when we really mean TLS 1.3, we still cannot deploy TLS 1.3 as-is without a TLS 1.2 fallback. Version-intolerant servers will continue to get deployed unnoticed. We need to get to a quiet point where the extension point works before we can start meaningfully applying GREASE. All GREASE does is try to exercise rarely-exercised extension point. Because I am unreasonably amused by this metaphor, if the joint has completely rusted shut already, we won't be able to get the GREASE in there. It needs to have some mobility left. Second, while the "joint" which handles new extensions IDs doesn't seem to be > rusting, it's not the case with lists in particular extensions. SNI being the > prime example where sending anything but a single host name value will most > likely lead to your client hello being either misinterpreted or rejected. > > > > But people will ~always be sending multiple elements in the list in the > version-negotiation extension -- you can't just send TLS 1.3; you also send > 1.2 for the near future. And if browsers are grease-ing from the > beginning, I don't really see this one rusting. > Right, SNI should just never have been an extension point. We have multi-valued lists elsewhere and they've worked fine. I can only speak to Chrome's experience, but we add cipher suites without worry. We successfully deployed X25519. RSA-PSS is going through the release process now. (We expect breakage from an old NSS bug, but probes of top sites suggest it will be tolerable.) TLS 1.3 adds even more lists. We're already assuming lists work. Yes, we find list intolerance too---servers which only look at the second byte in a cipher suite, servers which forgot a default in their NamedGroup switch-case, servers which get confused on unknown HashAlgorithms, servers which require the final extension non-empty---but this is dramatically less than version intolerance. It's usually within tolerable levels that we needn't resort to fallbacks. The proposal switches from something which we know does not work to something new. Perhaps this new one will break too, but it is very similar to things that have worked before, and I am hopeful that GREASE will help. David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
