Re: [TLS] PR for anti-downgrade mechanism

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

>
>
> On Mon, Nov 9, 2015 at 4:41 PM, Christian Huitema <huitema@microsoft.com>
> wrote:
>
>> On Monday, November 9, 2015 4:34 PM, Eric Rescorla wrote:
>>
>> > On Mon, Nov 9, 2015 at 4:30 PM, Christian Huitema <
>> huitema@microsoft.com> 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" ?
>> >
>> > We don't have one. Wasn't totally sure how to handle that.
>>
>> 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
>
>
>>
>> -- Christian Huitema
>>
>>
>>
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>