On Thu, Jun 2, 2016 at 10:59 AM Viktor Dukhovni <[email protected]> wrote:
> > > On Jun 2, 2016, at 10:49 AM, David Benjamin <[email protected]> > 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
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
