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. 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. 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. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
