No, you're right and I'm off : that value is in the past. I was treating it as a 64-bit epoch value. Bad me for having a 2038-ready timestamp interpreter.
On Mon, Nov 9, 2015 at 5:20 PM, Eric Rescorla <e...@rtfm.com> wrote: > On Mon, Nov 9, 2015 at 5:15 PM, Colm MacCárthaigh <c...@allcosts.net> > wrote: > >> >> 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? >> > > I believe that the current time is: +/- 56 41 46 1f > And the first 4 bytes are: 44 4F 57 4E, which should be in the past. > > Am I taking crazy pills? > > -Ekr > > > >> On Mon, Nov 9, 2015 at 3:52 PM, Eric Rescorla <e...@rtfm.com> 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 < >>> martin.thom...@gmail.com> wrote: >>> >>>> On 19 October 2015 at 08:08, Eric Rescorla <e...@rtfm.com> 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 >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> >> >> -- >> Colm >> > > -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
