On Sat, Oct 17, 2015 at 2:08 PM, Dave Garrett <[email protected]>
wrote:
> On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote:
> > The observation is still valuable in the sense that prohibiting values
> > > 1.3 would reduce the likelihood of a false positive by some
> > miniscule amount. In other words, I agree with ekr here, though we
> > could cap the value to 1.3.
> >
> > Maybe we could just define two values: one for TLS 1.3 (and greater,
> > presumably) and one for TLS 1.2. I don't see any value in protecting
> > 1.1 or 1.0 from downgrade any more given relative prevalence of those
> > protocols and their age.
>
> Two values seems like a good compromise to me if one isn't considered
> sufficient. I don't particularly want them changing in the future so old
> (e.g. TLS 1.3, in a future with TLS 1.4+) implementations don't need to
> worry about seeing something new here and making a mistake. Checks would be
> for one of two 64-bit values, rather than 56-bit values with a byte with a
> possibly unknown value
My assumption here was that the client would do the following:
1. Look to see if the server negotiated its highest version. If so, then
all is good.
2. If the server did not negotiate the highest version, then look for the
sentinel.
If it's set, you have a downgrade.
3. (Optional) If you have a downgrade, parse the last byte to see the
server's actual version.
In any case, abort.
What have I missed?
-Ekr
>
>
> Dave
>
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
