Would the values chosen there have a calamitous impact on Mon, 24 Dec 2125 11:21:51 GMT? I think that's the epoch when a regular TLS1.2 server would put that value in. I know it's 110 years in the future, but would it be better to choose a value that's in the past?
On Mon, Nov 9, 2015 at 3:52 PM, Eric Rescorla <[email protected]> wrote: > In an attempt to close the loop here, I've pushed a new PR version with a > 64-bit sentinel with the final byte being 00 for TLS 1.2 and 01 for TLS > 1.3. If anyone strongly objects to this construction, please raise your > hand now. > > Otherwise, I plan to merge this on Wednesday. > > https://github.com/tlswg/tls13-spec/pull/284 > > -Ekr > > > > On Mon, Oct 19, 2015 at 10:05 AM, Martin Thomson <[email protected] > > wrote: > >> On 19 October 2015 at 08:08, Eric Rescorla <[email protected]> wrote: >> > overloading the time field >> > lowers the risk of false positives because we can choose a sentinel that >> > will never >> > collide with a conformant TLS 1.2 ServerHello. By contrast, a sentinel >> in >> > the >> > randomly generated portion always has a 2^{-n} chance of collision. >> >> Yes, this is right. The marginal gain is that the proportion of >> servers that generate a time here are immune to collisions. If >> servers all servers did that, we wouldn't have to worry about >> collisions at all. Unfortunately, we do know that some generate random >> values. >> > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > > -- Colm
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
