Re: [TLS] Version negotiation, take two

[David Benjamin <[e-mail]>]

On Wed, Sep 14, 2016 at 11:46 AM Benjamin Kaduk <[e-mail]> 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