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

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 14 Nov 2016 13:58:35 +0100

Hi,
 For draft‐mavrogiannopoulos‐dtls‐cid‐00 and we needed to extend the
DTLS un-authenticated part of the DTLS record header with an additional
field. That works well if this is the only draft ever extending the
DTLS record header. If not, modification order would be undefined.

Would it make sense to introduce an extension header for DTLS 1.3 in
the lines of the IPv6 extension headers? That would allow TLS extension
negotiation to add more items on the un-authenticated header, and
potentially also remove redundant headers. 

What do you think?

regards,
Nikos

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Mon, 14 Nov 2016 13:36:35 +0000

Hi Nikos,

On 14/11/2016 12:58, "TLS on behalf of Nikos Mavrogiannopoulos"
<[email-masked] on behalf of [email-masked]> wrote:
>Hi,
> For draft-mavrogiannopoulos-dtls-cid-00 and we needed to extend the

In DTLS 1.3 we could probably re-purpose the version field to signify
"header version" instead?

---

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

> DTLS record header. If not, modification order would be undefined.

Where is this draft?

> potentially also remove redundant headers.

Without seeing the draft, I can't really say whether this is sensible,
but I've been working on trimming the DTLS 1.3 header down to
something sane.  That might be incompatible with any attempt to add
unauthenticated data to the header.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Nov 2016 09:28:01 +0900

One way to split the difference between these two would be to use an
extension to negotiate the encrypted record format.

-Ekr

On Tue, Nov 15, 2016 at 9:10 AM, Martin Thomson <[email-masked]>
wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Nov 2016 09:35:50 +0900

> extension to negotiate the encrypted record format.

Yes, that could work.  It would need special rules for 0-RTT, but in
theory a negotiated extension could do anything to the protocol.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Nov 2016 09:38:59 +0900

See also PR#762

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Nov 2016 01:10:13 +0000

> potentially also remove redundant headers. 

I'd be interested in an analysis of the potential privacy
impacts of this. Isn't this more or less the same as doing
SPUD-for-DTLS? (If not, sorry for dragging in controversy:-)

S.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Nov 2016 10:16:25 +0900

On Tue, Nov 15, 2016 at 10:10 AM, Stephen Farrell <[email-masked]

> SPUD-for-DTLS? (If not, sorry for dragging in controversy:-)

It would no doubt depend what you put there.

-Ekr

---

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

> It would no doubt depend what you put there.

Which is why I'm interested in seeing Nikos' (unpublished?) draft.

---

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

>Which is why I'm interested in seeing Nikos' (unpublished?) draft.

Published:
https://tools.ietf.org/html/draft-mavrogiannopoulos-tls-cid-00

Working copy:
https://thomas-fossati.github.io/draft-tls-cid/

Slides for today, "DTLS Optimizations for IoT Deployments":
https://www.ietf.org/proceedings/97/slides/slides-97-tls-dtls-optimizations
-for-iot-deployments-00.pptx

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 15 Nov 2016 08:12:57 +0100

> SPUD-for-DTLS? (If not, sorry for dragging in controversy:-)

You can check the security considerations section of the latest draft:
https://github.com/thomas-fossati/draft-tls-cid/blob/master/draft-mavrogiannopoulos-tls-cid.md

TLDR; the privacy offered by this extension is the same as the privacy
of DTLS over UDP.

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 15 Nov 2016 08:09:17 +0100

> > DTLS record header. If not, modification order would be undefined.

The published version:

The latest:

regards,
Nikos

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Nov 2016 16:36:17 +0900

> TLDR; the privacy offered by this extension is the same as the privacy

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.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 14 Nov 2016 23:39:19 -0800

> have privacy issues would be overstating the case.

I thought we were going to kill NAT with IPv6, but apparently you
can't remove bad ideas from the Internet. Another place where
connection IDs are needed is with mobile clients: anyone who has used
ssh while switching networks knows the pain the lack of a connection
ID distinct from the 4-tuple brings.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Nov 2016 01:59:27 +0000

Ø  I'd be interested in an analysis of the potential privacy
impacts of this. Isn't this more or less the same as doing
SPUD-for-DTLS? (If not, sorry for dragging in controversy:-)

I don’t know SPUD but I see this work providing the same functionality as the Security Parameter Index (SPI) in the IPsec ESP RFC.
So far, I have not heard terrible concerns about the privacy properties of IPsec ESP.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Nov 2016 02:03:27 +0000

> So far, I have not heard terrible concerns about the privacy properties of IPsec ESP.

Yes, to be fair - having had a quick look at the draft it
does not seem to have the problems that SPUD/PLUS could have
had.

Cheers,
S.

---

From: "Kraus Achim (INST/ESY1)" <[email-masked]>
Date: Wed, 16 Nov 2016 10:21:41 +0000

Hi,

I'm still wondering, why the "clashing" calculations (section 4) are only based on the number of clients and not also on the length of the hash chain.
As I understood the hash chain, the DTLS server and client calculates a list of CIDs. Though the client chose one, the server has to prepare for the (left) list of CIDs. So even assuming that in average half of the list is already used, I think the length of that list has influence on the clashing.

Mit freundlichen Grüßen / Best regards

Achim Kraus

Bosch Software Innovations GmbH
Communications (INST/ESY1)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com 

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn

-----Ursprüngliche Nachricht-----
Von: TLS [mailto:[email-masked]] Im Auftrag von Fossati, Thomas (Nokia - GB)
Gesendet: Dienstag, 15. November 2016 08:08
An: Martin Thomson <[email-masked]>; Eric Rescorla <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; [email-masked]
Betreff: Re: [TLS] [ALU] Re: extending the un-authenticated DTLS header

On 15/11/2016 03:51, "TLS on behalf of Martin Thomson"
<[email-masked] on behalf of [email-masked]> wrote:
>>> I'd be interested in an analysis of the potential privacy impacts of 
>>> this. Isn't this more or less the same as doing SPUD-for-DTLS? (If 
>>> not, sorry for dragging in controversy:-)
>>
>>

Published:

Working copy:

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Thu, 17 Nov 2016 23:01:24 +0000

Hi Achim,

On 16/11/2016 10:21, "TLS on behalf of Kraus Achim (INST/ESY1)"
<[email-masked] on behalf of [email-masked]> wrote:
>I'm still wondering, why the "clashing" calculations (section 4) are only
>based on the number of clients and not also on the length of the hash
>chain.

I guess you are right.  The left column should say "sessions x
window_size".