Re: [TLS] PR for anti-downgrade mechanism

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 <ekr@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.thomson@gmail.com
> > wrote:
>
>> On 19 October 2015 at 08:08, Eric Rescorla <ekr@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