On 02/06/16 18:16, David Benjamin wrote:
On Thu, Jun 2, 2016 at 10:59 AM Viktor Dukhovni <ietf-d...@dukhovni.org
<mailto:ietf-d...@dukhovni.org>> wrote:
> On Jun 2, 2016, at 10:49 AM, David Benjamin
<david...@chromium.org <mailto:david...@chromium.org>> wrote:
>
> I'm not sure I follow. The specification certainly spells out how
version negotiation is supposed to work. That hasn't stopped servers
from getting it wrong. Fundamentally this is the sort of thing where
bugs don't get noticed until we make a new TLS version, and we don't
do that often enough to keep rust from gathering.
A better way to keep rust from gathering is to not instutionalize
fallback,
force the broken sites to deal with the issue. While 2% is
noticeable, you
can probably drive 1.3 version intolerance out of the ecosystem
relatively
quickly if Chrome implements fallback for a limited time (say 6
months after
TLS 1.3 RFC is done) and with a diminishing probability (60% first
month, 10%
less each month thereafter), season to taste.
I've mused on something like that (I was the main driver behind
painstakingly removing the existing version fallback in Chrome), but I
don't think non-determinism is a good idea. Site owners need to be able
to reproduce the failures their users see.
But, yes, I will of course be monitoring the true metrics (my probing a
list of sites is only an approximation) and seeing what can be done
here, as I did previously.
David
Taking Viktor's proposal in a different direction, you could gradually
increase the probability of version intolerance on the client side while
still remaining deterministic from the user's point of view. You could
do it by choosing a random distribution over server names (e.g., a hash
of the SNI value). This means every month a few new servers would break.
And you would want the client's beta channel to run several steps ahead
of the production version.
Thanks,
Yaron
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
