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

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Tue, 15 Nov 2016 08:34:50 +0000

On 15/11/2016 07:36, "TLS on behalf of Martin Thomson"
<[email-masked] on behalf of [email-masked]> wrote:
>On 15 November 2016 at 16:12, Nikos Mavrogiannopoulos <[email-masked]>
>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.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Nov 2016 18:10:04 +0900

> reasons for having both methods.

I'm not seeing quite enough information here to implement this.  How
does a server know which of the many HOTP keys it has are in use?
Surely you can't use the same HOTP key with every client.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 15 Nov 2016 10:11:37 +0100

> Surely you can't use the same HOTP key with every client.

Not sure I understand the question, but I'd suggest to read the text on
generating the hotp keys.

regards,
Nikos

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Nov 2016 18:20:04 +0900

> generating the hotp keys.

OK, I re-read it.  It wasn't particularly clear from the overview.
But you generate the HOTP based on an exporter.  That means that the
server has no control over the contents of the CID, direct or
otherwise.  This means that you can guarantee privacy, but it forces
the server to do an exhaustive search of all of its active connections
(that is, O(N)) when it gets a 5-tuple mismatch.

There are probably designs that don't have this property.  For
instance, the server could propose an identifier or set of
identifiers.  That means that a bad server could willfully break the
privacy property, but it also means that it doesn't have the scaling
issues.

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Tue, 15 Nov 2016 09:30:35 +0000

On 15/11/2016 09:20, "TLS on behalf of Martin Thomson"
<[email-masked] on behalf of [email-masked]> wrote:
>This means that you can guarantee privacy, but it forces

I don't think I follow.  You'd use CID as primary key to index your
security contexts.  So, regardless your 5-tuple matches or not you'd do
your O(1) lookup in the CID table and find the associated security context.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Nov 2016 19:12:40 +0900

Okay, so you are saying that every packet has the same number?

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 16 Nov 2016 08:37:00 +0100

> privacy property, but it also means that it doesn't have the scaling

I think Thomas reply addresses that, or we must have misunderstood what
you mean above. I think however that we are getting outside the scope
of the initial discussion. Do you have a proposal which changes the
TLSrecord header? If yes would you be interested in discussing ways to
combine that, or ways to make the header extendable?

regards,
Nikos