On Sat, Oct 17, 2015 at 2:34 PM, Dave Garrett <davemgarr...@gmail.com>
wrote:
> On Saturday, October 17, 2015 05:16:49 pm Eric Rescorla wrote:
> > On Sat, Oct 17, 2015 at 2:08 PM, Dave Garrett <davemgarr...@gmail.com>
> > 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?
>
> A 64-bit sentinel can be trivially checked as a 64-bit uint.
And a 56-bit value can be trivially checked by masking off the last byte.
Or, memcmp().
If we have an open-ended series, we could have implementations checking for
> a set of 64-bit integers,rather than a 56-bit followed by another byte to
> be inspected.
As noted, nobody is making you check it.
> I'm being paranoid, yes, but it's simpler just to have a round number bits
> value or two and I don't think you get much by encoding further information.
>
> It also has a slightly better collision risk, though it's already down
> quite low
Given that the TCP checksum has a false negative rate far higher than
2^{-56} and
any TCP errors cause TLS handshake failures, this doesn't seem like much of
an argument.
-Ekr
>
> Dave
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
