Subject: Re: [TLS] PR for anti-downgrade mechanism

From: Eric Rescorla <[email-masked]>
Date: Mon, 9 Nov 2015 15:52:40 -0800

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-masked]>
wrote:

> On 19 October 2015 at 08:08, Eric Rescorla <[email-masked]> 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.
>

---

From: Christian Huitema <[email-masked]>
Date: Tue, 10 Nov 2015 00:30:44 +0000

On Monday, November 9, 2015 3:53 PM, Eric Rescorla 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.
>

Editorial: your proposed text says "...MUST set the first six  bytes of its Random value to the the bytes 44 4F 57 4E 47 52 44 01." I assume you mean the first 8 bytes, and that you do not really want to have "the" twice. 

Could you also add a reference to the document that specifies using 44 4F  57 4E 47 52 44 00 by "TLS 1.2 servers which are  negotiating TLS 1.1 or below" ?

-- Christian Huitema

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 9 Nov 2015 16:34:10 -0800

On Mon, Nov 9, 2015 at 4:30 PM, Christian Huitema <[email-masked]>
wrote:

> Editorial: your proposed text says "...MUST set the first six  bytes of
> its Random value to the the bytes 44 4F 57 4E 47 52 44 01." I assume you
> mean the first 8 bytes, and that you do not really want to have "the" twice.
>

Fixed.

Could you also add a reference to the document that specifies using 44 4F
> 57 4E 47 52 44 00 by "TLS 1.2 servers which are  negotiating TLS 1.1 or
> below" ?

We don't have one. Wasn't totally sure how to handle that.

-Ekr

---

From: Christian Huitema <[email-masked]>
Date: Tue, 10 Nov 2015 00:41:34 +0000

On Monday, November 9, 2015 4:34 PM, Eric Rescorla wrote:

> On Mon, Nov 9, 2015 at 4:30 PM, Christian Huitema <[email-masked]> wrote:
>
>...
>> Editorial: your proposed text says "...MUST set the first six  bytes of its Random value 
>> to the the bytes 44 4F 57 4E 47 52 44 01." I assume you mean the first 8 bytes, and that 
>> you do not really want to have "the" twice.
>
> Fixed.

Thanks

>> Could you also add a reference to the document that specifies using 44 4F  57 4E 47 52 
>> 44 00 by "TLS 1.2 servers which are  negotiating TLS 1.1 or below" ?
>

I suspected that. Spent sometimes looking for text in published RFC, could not find it. I suspect that many readers will fall in the same trap and lose some time. Could you add text explaining that this is an undocumented feature of some implementations, and that we are recommending its use? Or something to that effect...

-- Christian Huitema

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 9 Nov 2015 16:44:22 -0800

On Mon, Nov 9, 2015 at 4:41 PM, Christian Huitema <[email-masked]>
wrote:

> its Random value
> I suspected that. Spent sometimes looking for text in published RFC, could
> not find it. I suspect that many readers will fall in the same trap and
> lose some time. Could you add text explaining that this is an undocumented
> feature of some implementations, and that we are recommending its use? Or
> something to that effect...
>

Worse, we just invented it. What about if I say "TLS 1.2 servers SHOULD..."

-Ekr

---

From: Christian Huitema <[email-masked]>
Date: Tue, 10 Nov 2015 00:54:25 +0000

On Monday, November 9, 2015 4:44 PM, Eric Rescorla wrote:
> On Mon, Nov 9, 2015 at 4:41 PM, Christian Huitema <[email-masked]> wrote:
>> I suspected that. Spent sometimes looking for text in published RFC, 
>> could not find it. I suspect that many readers will fall in the same trap 
>> and lose some time. Could you add text explaining that this is an 
>> undocumented feature of some implementations, and that we are 
>> recommending its use? Or something to that effect...
>

That would be better. There is however a question of "is this the right document." This is the spec for TLS 1.3 servers, so implementers of TLS 1.2 servers may or may not read it. This document "obsoletes 5246," so cannot really update it. Let see what you come up with...

-- Christian Huitema

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 9 Nov 2015 17:15:21 -0800

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-masked]> wrote:

> On Mon, Oct 19, 2015 at 10:05 AM, Martin Thomson <[email-masked]
> > wrote:
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

-- 
Colm

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 9 Nov 2015 17:29:37 -0800

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 <[email-masked]> wrote:

> On Mon, Nov 9, 2015 at 5:15 PM, Colm MacCárthaigh <[email-masked]>
> 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
>
>
>
>>> 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
>>> On Mon, Oct 19, 2015 at 10:05 AM, Martin Thomson <
>>> [email-masked]> wrote:
>>>

-- 
Colm

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 25 Nov 2015 11:12:29 -0800

It looks like we have rough consensus to accept this PR.  We should make
sure we note the limitations that Karthink brought up for PSK and RSA,
https://mailarchive.ietf.org/arch/msg/tls/sZX9ursx4ePK2Zr-yflO2nUtiQY.
Procedurally, we should document the requirements for TLS 1.2 in a separate
draft to update TLS 1.2 in parallel.   This may be necessary to get us out
of the situation where we have to update and obsolete a specification at
the same time.

Thanks,

J&S

On Mon, Nov 9, 2015 at 4:44 PM, Eric Rescorla <[email-masked]> wrote:

>> undocumented feature of some implementations, and that we are recommending
>> its use? Or something to that effect...
>>
>