Re: [TLS] PR for anti-downgrade mechanism

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 <ekr@rtfm.com> wrote:

> On Mon, Nov 9, 2015 at 5:15 PM, Colm MacCárthaigh <colm@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 <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
>>
>
>

-- 
Colm