Re: [TLS] extending the un-authenticated DTLS header

["Fossati, Thomas (Nokia - GB)" <[e-mail]>]

On 15/11/2016 07:36, "TLS on behalf of Martin Thomson"
<[e-mail] on behalf of [e-mail]> wrote:
>On 15 November 2016 at 16:12, Nikos Mavrogiannopoulos <[e-mail]>
>wrote:
>> TLDR; the privacy offered by this extension is the same as the privacy
>> of DTLS over UDP.
>
>I disagree.  All the privacy considerations of the QUIC connection ID
>apply here.  It would probably pay to follow that discussion.
>
>If the intent of this is simply to deal with the NAT rebinding issue,
>then I think that this is worth doing, but to say that this does not
>have privacy issues would be overstating the case.

I agree.  We had previous discussion on and off list about this and we
took Stephen's point to look at ways to make this identifier privacy
friendly.

The draft proposes two ways to allocate the identifier (see 3rd para of
https://thomas-fossati.github.io/draft-tls-cid/#rfc.section.1):
1. Server decides unilaterally a value that is fixed for the duration of
the session (SecAssocType.fixed);
2. Server and Client agree on a sequence of values generated using HOTP
[RFC 4226] seeded by the session shared secret (SecAssocType.hotp); Client
shifts to the next value when needed (e.g. on transport handover).


At first this might not look particularly elegant, but there are good
reasons for having both methods.