Subject: Re: [core] Question reg. draft-fossati-tls-iot-optimizations-00

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Wed, 2 Nov 2016 09:34:56 +0000

Hi Kai, Achim (sorry for the late reply, I wasn't looking at the TLS list).

IIRC the idea came from Stephen (Farrell) in an attempt to add
privacy-preserving properties to the (potentially) long term identifier.

It's clearly a strawman and I'm happy to discuss its merits (in particular
the fact that when NAT rebinding happens without the client knowing it in
advance, the privacy of this is already gone) and impact in the IoT space
(in term of state that is kept on server side if handling multiple
connections at a time).

However, whatever the mechanism we come up with, I think privacy
preservation should be a goal, or at least something that is taken as a
first class criterion for selection.

Cheers, t

On 02/11/2016 07:29, "core on behalf of Hudalla Kai (INST/ESY1)"
<[email-masked] on behalf of [email-masked]> wrote:
>Hi list,
>
>I have attended last week's meeting of the T2T RG in Ludwigsburg where we
>had a
>vivid discussion around the problems of DTLS on mobile and other NATed
>networks
>where the device's IP address and/or port are expected to change once in
>a while.
>
>We quickly came to the conclusion that the CoAP spec will need to be
>changed in a
>way that removes the transport's addressing information from the
>Request/Response
>matching criteria when using DTLS.
>
>However, what alternative mechanism could be used instead?
>
>Section 4.2 of draft-fossati-tls-iot-optimizations-00 proposes to use a
>connection ID as part of the DTLS record structure. While I understand the
>usefulness of using a "long term identifier" for associating the session
>with the
>client, I do not really understand, how a "hash chain" could be put to
>use in
>this context to provide an improved level of privacy.
>
>Could someone (of the authors) comment on that?
> 
>-- 
>Mit freundlichen Grüßen / Best regards
>
>Kai Hudalla
>Chief Software Architect
>
>Bosch Software Innovations GmbH
>Schöneberger Ufer 89-91
>10785 Berlin
>GERMANY
>www.bosch-si.com
>
>Registered office: Berlin, Register court: Amtsgericht Charlottenburg,
>HRB 148411 B;
>Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>_______________________________________________
>core mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/core

---

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

Hi Thomas,

thanks for your answer. 
Though draft-fossati-tls-iot-optimizations-00 was published in the tls wg, I posted my question there.

Currently I'm simply not sure, if I understood the approach right, but according your answer, 
I guess Stephen (Farrell) may be the right person, to give an answer.

With my understanding (see mail in tls, https://www.ietf.org/mail-archive/web/tls/current/msg21737.html),

I see following issues with the hash chain:
The scaling/performance depends on the "hash chain window" used to related the record to the dtls connection.
As larger the window, the more I'm in doubt, if that scales.
The robustness for clients, when we lose more packets then we assume in the window.
As smaller the window, the more I'm in doubt, if it's robust enough.

There may be an escape using the "record sequence number" in a more sophistic way
(e.g. using H(record.sequence_numer | connection_id) would help to skip faster over 
lost messages, but still with a large number of clients/connections, I don't see how this
scales). But right now I guess, we need more guidance, how it was intended.

Therefore I could think also of an alternative solution with an "connection id ticket" system.
The DTLS server sends after the handshake a ticket with the "encrypted connection id".
The DTLS client decrypts that ticket into the connection id and, if the client later  
didn't receive a message for a certain period of time (e.g. 20s), it adds that connection id to
the records until it receives a new ticket (encrypted new connection id) .
When the client receives a new ticket, then it could send the messages again without the 
connection id until it doesn't receive messages for the certain period of time, after which
the new ticket is used.
The DTLS server only accepts records with that "decrypted" connection id, if the MAC check is passed.
It the adjusts the address/port and emits a new ticket. If the DTLS server receives "invalid" 
(or no longer valid) connection ids, it uses the current address/port mapping to check the MAC and ignores
the message, when the check fails. 
The advantage of that would be, that "high frequent" traffic doesn't require such a connection id,
so it would just be used for "rarely" communicating client periods. Indicate with an extension, it would
leave the current DTLS implementation unchanged as long as they are proper working right now and
just offer an extension to those, wo would require it because of either to frequent address changes or
to limited bandwidth (for dtls resumes/handshakes).
And the server only needs those tickets, if the client and the server agrees on using them.

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: core [mailto:[email-masked]] Im Auftrag von Fossati, Thomas (Nokia - GB)
Gesendet: Mittwoch, 2. November 2016 10:35
An: Hudalla Kai (INST/ESY1) <[email-masked]>; [email-masked]
Betreff: Re: [core] Question reg. draft-fossati-tls-iot-optimizations-00

IIRC the idea came from Stephen (Farrell) in an attempt to add privacy-preserving properties to the (potentially) long term identifier.

It's clearly a strawman and I'm happy to discuss its merits (in particular the fact that when NAT rebinding happens without the client knowing it in advance, the privacy of this is already gone) and impact in the IoT space (in term of state that is kept on server side if handling multiple connections at a time).

However, whatever the mechanism we come up with, I think privacy preservation should be a goal, or at least something that is taken as a first class criterion for selection.

Cheers, t

On 02/11/2016 07:29, "core on behalf of Hudalla Kai (INST/ESY1)"
<[email-masked] on behalf of [email-masked]> wrote:
>Hi list,
>
>I have attended last week's meeting of the T2T RG in Ludwigsburg where 
>we had a vivid discussion around the problems of DTLS on mobile and 
>other NATed networks where the device's IP address and/or port are 
>expected to change once in a while.
>
>changed in a way that removes the transport's addressing information 
>from the Request/Response matching criteria when using DTLS.
>
>connection ID as part of the DTLS record structure. While I understand 
>the usefulness of using a "long term identifier" for associating the 
>session with the client, I do not really understand, how a "hash chain" 
>could be put to use in this context to provide an improved level of 
>privacy.
>

---

From: Simon Bernard <[email-masked]>
Date: Wed, 2 Nov 2016 17:08:34 +0100

Hi all,

    I'm not sure to understand the point here.
    *   The "draft-fossati-tls-iot-optimizations-00" says "The privacy 
issue associated with the use of a long-term identifier
    must be taken into consideration."
    *   Thomas says "I think privacy preservation should be a goal".

    I would like to understand which privacy concern we would like to 
achieve exactly ? With TLS we have end to end encryption. You want to 
add a kind of  anonymity ? or maybe protect ourself from connectionid 
spoofing ?
    From my point of view, the connection id is just a way to replace 
the IP address by a connection identifier for use-cases where IP address 
is not fixed. So we have the same security level with connection id than 
fixed IP. We are maybe a bit more exposed to spoofing as connectionid 
spoofing is probably more simple than UDP IP address spoofing, but not 
so much. I mean connectionid is just another way to retrieve security 
context needed to decrypt Application Data.

    About CoAP Observation behind a NAT using DTLS, I think we have 
several issues.

    *  First one: define a long term identifier for CoAP. At CoAP level 
users would like to know from which or to which they send data, nothing 
more. IMHO, using the DTLS identity seems the better choice. (PSK 
identity for PSK, public key for RPK, CN for certificate). From my point 
of view there is no need to strongly link this to the DTLS session as it 
was currently the case in CoAP spec [1][2]. Nobody seems really able to 
explain this choice and this doesn't work behind NAT. With this 
constraint, it can also be tempting to increase the session lifetime to 
be able to increase the observation lifetime which seems not to be a 
good idea as security level.
    *  Second point: be able to use DTLS with dynamic IP address (e.g. 
NAT) without the need to redo full handshake or resume handshake. The 
"connectionId" proposed in this draft seems to resolve the issue. It 
could also really help to do load balancing using this connectionid 
instead of IP address in a cluster environment.

Simon

[1]https://tools.ietf.org/html/rfc7641#section-7 (All notifications 
resulting from a GET request with an Observe Option MUST be returned 
within the same epoch of the same connection as the request.)
[2]https://tools.ietf.org/html/rfc7252#section-9.1.1 (The DTLS session 
MUST be the same, and the epoch MUST be the same.)

---

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

Hi,

> IMHO, using the DTLS identity seems the better choice. (PSK identity for PSK, public key for RPK, CN for certificate).

For PSK identity, and CN certificate they may be a choice.

But for RPK, can you explain, how the identity is checked on DTLS layer?

Achim Kraus

-----Ursprüngliche Nachricht-----
Von: Simon Bernard [mailto:[email-masked]] 
Gesendet: Mittwoch, 2. November 2016 17:09
An: Kraus Achim (INST/ESY1) <[email-masked]>; [email-masked]
Betreff: Re: [core] Question reg. draft-fossati-tls-iot-optimizations-00

Hi all,

    I would like to understand which privacy concern we would like to achieve exactly ? With TLS we have end to end encryption. You want to add a kind of  anonymity ? or maybe protect ourself from connectionid spoofing ?
    From my point of view, the connection id is just a way to replace the IP address by a connection identifier for use-cases where IP address is not fixed. So we have the same security level with connection id than fixed IP. We are maybe a bit more exposed to spoofing as connectionid spoofing is probably more simple than UDP IP address spoofing, but not so much. I mean connectionid is just another way to retrieve security context needed to decrypt Application Data.

    About CoAP Observation behind a NAT using DTLS, I think we have several issues.

    *  First one: define a long term identifier for CoAP. At CoAP level users would like to know from which or to which they send data, nothing more. IMHO, using the DTLS identity seems the better choice. (PSK identity for PSK, public key for RPK, CN for certificate). From my point of view there is no need to strongly link this to the DTLS session as it was currently the case in CoAP spec [1][2]. Nobody seems really able to explain this choice and this doesn't work behind NAT. With this constraint, it can also be tempting to increase the session lifetime to be able to increase the observation lifetime which seems not to be a good idea as security level.
    *  Second point: be able to use DTLS with dynamic IP address (e.g. 
NAT) without the need to redo full handshake or resume handshake. The "connectionId" proposed in this draft seems to resolve the issue. It could also really help to do load balancing using this connectionid instead of IP address in a cluster environment.

Simon

[1]https://tools.ietf.org/html/rfc7641#section-7 (All notifications resulting from a GET request with an Observe Option MUST be returned within the same epoch of the same connection as the request.)
[2]https://tools.ietf.org/html/rfc7252#section-9.1.1 (The DTLS session MUST be the same, and the epoch MUST be the same.)

Le 02/11/2016 à 11:33, Kraus Achim (INST/ESY1) a écrit :

> Currently I'm simply not sure, if I understood the approach right, but 
> according your answer, I guess Stephen (Farrell) may be the right person, to give an answer.
>
> With my understanding (see mail in tls, 
> https://www.ietf.org/mail-archive/web/tls/current/msg21737.html),
>
> There may be an escape using the "record sequence number" in a more 
> sophistic way (e.g. using H(record.sequence_numer | connection_id) 
> would help to skip faster over lost messages, but still with a large 
> number of clients/connections, I don't see how this scales). But right now I guess, we need more guidance, how it was intended.
>
> The DTLS client decrypts that ticket into the connection id and, if 
> the client later didn't receive a message for a certain period of time 
> (e.g. 20s), it adds that connection id to the records until it receives a new ticket (encrypted new connection id) .
> When the client receives a new ticket, then it could send the messages 
> again without the connection id until it doesn't receive messages for 
> the certain period of time, after which the new ticket is used.
> (or no longer valid) connection ids, it uses the current address/port 
> mapping to check the MAC and ignores the message, when the check fails.
> The advantage of that would be, that "high frequent" traffic doesn't 
> require such a connection id, so it would just be used for "rarely" 
> communicating client periods. Indicate with an extension, it would 
> leave the current DTLS implementation unchanged as long as they are 
> proper working right now and just offer an extension to those, wo would require it because of either to frequent address changes or to limited bandwidth (for dtls resumes/handshakes).
> HRB 148411 B
>> I have attended last week's meeting of the T2T RG in Ludwigsburg 
>> where we had a vivid discussion around the problems of DTLS on mobile 
>> and other NATed networks where the device's IP address and/or port 
>> are expected to change once in a while.
>>
>> Section 4.2 of draft-fossati-tls-iot-optimizations-00 proposes to use 
>> a connection ID as part of the DTLS record structure. While I 
>> understand the usefulness of using a "long term identifier" for 
>> associating the session with the client, I do not really understand, how a "hash chain"
>> Registered office: Berlin, Register court: Amtsgericht 
>> Charlottenburg, HRB 148411 B;

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Wed, 2 Nov 2016 16:52:46 +0000

Hi Simon,

>add a kind of  anonymity ? or maybe protect ourself from connectionid

The issue is that something like CID will make tracking a device activity
across different transports very easy.  (Personally, I think NAT rebinding
is a bit different because it usually happens without client awareness,
and therefore already exposes correlation information to a possible
tracker.)

In any case, if we make this an extension of the general TLS protocol we
need to make sure we design it in a way that a) is fit for the purpose
from a functional and security perspective, and b) takes into
consideration the tracking aspects for clients that want to have finer
control on their privacy.

>context needed to decrypt Application Data.

ISTM that if CID has enough randomness and is integrity-protected, then
spoofing is not an issue (or it is less an issue than security context
lookup based on a fully tamperable 5-tuple).  But certainly this is a
dimension to explore further (e.g. depending on the way CID is
synchronised on the two sides, there might be opportunities for an
attacker that can selectively drop packets from the network to do
different things, I guess).

Cheers, t

---

From: Simon Bernard <[email-masked]>
Date: Wed, 2 Nov 2016 18:17:58 +0100

I think identity is not checked at DTLS layer, but at the CoAP Layer. 
For RPK we can use the public key.

I mean the DTLS layer ensure encryption and authentication.
At CoAP level, you will get your decrypted data and the DTLS identity, 
up to you to ensure you talk to the right peer.
For example, if you add the LWM2M Layer where peer are identified by 
registration endpoint , you need to associate this registration endpoint 
to a DTLS identity (the public key for RPK).

---

From: Simon Bernard <[email-masked]>
Date: Wed, 2 Nov 2016 18:22:06 +0100

With TLS 1.2 we currently don't have this tracking aspect consideration 
? Identity is sent in clear, by sniffing the network you could know who 
send to who. This seems to me like another issue/feature.

Currently TLS don't protect you from tracking or provide you any 
anonymity : "The primary goal of the TLS protocol is to provide privacy 
and data integrity between two communicating applications." (+ 
authentication)

As a wiseman tell to me : "one step at a time !".

(ConnectionID will have a lifetime less or equals than the session 
lifetime, this means 24h maximum. This limit the tracking activity based 
on connectionID to 24h)

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 2 Nov 2016 19:25:56 +0100

Hi Simon,

On 11/02/2016 05:08 PM, Simon Bernard wrote:
> achieve exactly ?

The privacy concern is correlation by linking independent TLS sessions
together (see RFC 6973).

Ciao
Hannes

---

From: Simon Bernard <[email-masked]>
Date: Thu, 3 Nov 2016 11:29:58 +0100

If this is really about linking independent TLS sessions. I think there 
is no problem here.

Because "Sessions define a set of cryptographic security parameters that 
can be shared among multiple connections." (RFC 5246)

So a connection is alway linked to only 1 sessions, So a CID is alway 
linked to 1 sessions.

This means CID can not be used to linked independent TLS sessions.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 3 Nov 2016 14:56:30 +0000

Super, Sebastien!

I'll help as much as I can. I have a conflict on Thursday but will try to show up as much as I can.

Take care,

Pascal