Subject: [T2TRG] dtls resume

From: Daniel Lux <[email-masked]>
Date: Thu, 03 Nov 2016 09:39:31 +0100

During our meeting in Ludwigsuburg at the implementers workshop we
discussed the DTLS resume problem.
This problem occurs when a constrained device behind a NAT communicates
with a server and the NAT changes the
UDP source port or the IP address of the sending constrained device,
while the server uses the source address and port number
to identify the DTLS connection.

One other solution than adding a parameter to the DTLS records would be
to construct the IV/NONCE in a way that
allows the server to identify the session from that information.
This would mean that we would need to specify a new cipher suite, but
otherwise it might be an elegant solution.
Has anybody suggested this kind of solution to the resume problem?

Kind regards

  Daniel
-- 
Daniel Lux
Tlf: (+45)-46 922 722

Seluxit

Hjulmagervej 32B

9000 Aalborg

Denmark

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 03 Nov 2016 10:33:41 +0100

Daniel,

Daniel Lux <[email-masked]> writes:

> One other solution than adding a parameter to the DTLS records would
> be to construct the IV/NONCE in a way that

Doesn't this make the IV/NONCE less random?

Grüße
Olaf

---

From: Daniel Lux <[email-masked]>
Date: Thu, 03 Nov 2016 10:41:31 +0100

Hi Olaf,
The IV/NONCE does not need to be random. 
The security comes from the encryption algorithm + key strength and not
the NONCE.
Kind regards
		Daniel
-- 
Daniel Lux
Tlf: (+45)-46 922 722
Seluxit
Hjulmagervej 32B
9000 Aalborg
Denmark

 	 We are currently working on:
* New gateway version
* ENCOURAGE EU project
* Mobile Phone program

---

From: Joerg Ott <[email-masked]>
Date: Thu, 3 Nov 2016 19:57:28 +0100

Hi,

many people have worked on suspend/resume features for transport
protocols and persistent connection identifiers always played some
kind of a role.

I am aware of one paper that designed extensions to TLS/SSH:
http://infrahip.hiit.fi/papers/resilient.pdf
(published in Usenix 2006)

I am not a security person but I would not sign that you
should give up on the Nonce/IV randomness.

Jörg

On 03.11.16 10:41, Daniel Lux wrote:
>> Daniel Lux <[email-masked] <mailto:[email-masked]>> writes:
>>
>>> be to construct the IV/NONCE in a way that allows the server to
>>> identify the session from that information. This would mean that we
>>> would need to specify a new cipher suite, but otherwise it might be
>>> an elegant solution. Has anybody suggested this kind of solution to
>>> the resume problem?
>>
>>
> Seluxit Logo 	We are currently working on:
>
>     * New gateway version
>     * ENCOURAGE EU project
>     * Mobile Phone program
>
>
>
>
> _______________________________________________
> T2TRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/t2trg
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 3 Nov 2016 20:09:04 +0100

Section 4 of
https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00

Ciao
Hannes

---

From: Daniel Lux <[email-masked]>
Date: Thu, 03 Nov 2016 22:24:14 +0100

Hi Jörg,
From https://tools.ietf.org/html/rfc5288:
	Each value of the nonce_explicit MUST be distinct for each
distinct
   	invocation of the GCM encrypt function for any fixed key. 
Failure to
   	meet this uniqueness requirement can significantly degrade
security.
   	The nonce_explicit MAY be the 64-bit sequence 
Actually if the nonce is completely random, it is hard and memory
intensive to protect the recipient against replay 
attacks.
/Daniel
On Thu, 2016-11-03 at 19:57 +0100, Joerg Ott wrote:
> > > Daniel Lux <[email-masked] [email-masked]>>
> > > writes:
> > > 
> > > > 
-- 
Daniel Lux
Tlf: (+45)-46 922 722
Seluxit
Hjulmagervej 32B
9000 Aalborg
Denmark

---

From: Daniel Lux <[email-masked]>
Date: Thu, 03 Nov 2016 22:33:07 +0100

Thanks, I was searching for that document.
He is however if I read it right, suggesting to change the DTLS record
layer header and not the nonce used for the cipher.
Making a specific cipher for constrained devices, 
where the nonce is reduced to 6 or even only 5 bytes (requiring re-
negotiation when roll over is approaching),
would not require to change the DTLS record layer header.
I don't know however what is easier to push through, changing the
header or introducing a new cipher?
/daniel
-- 
Daniel Lux
Tlf: (+45)-46 922 722
Seluxit
Hjulmagervej 32B
9000 Aalborg
Denmark

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 3 Nov 2016 17:17:02 -0500

On Thu, Nov 3, 2016 at 3:39 AM, Daniel Lux <[email-masked]> wrote:
> During our meeting in Ludwigsuburg at the implementers workshop we discussed
> the DTLS resume problem.
> This problem occurs when a constrained device behind a NAT communicates with
> a server and the NAT changes the
> UDP source port or the IP address of the sending constrained device, while
> the server uses the source address and port number

This is the first time I hear NAT usage in IoT. Can you please let me
know what was the setup, scenario?

Regards,

Behcet
>
> One other solution than adding a parameter to the DTLS records would be to
> construct the IV/NONCE in a way that

---

From: Daniel Lux <[email-masked]>
Date: Fri, 04 Nov 2016 10:38:07 +0100

Hi Behcet,
IoT devices behind one or multiple NAT's is quiet common.
This happens when an IoT device connects to a server, while it is for
example installed using a home owners internet connection.
Even a lot of mobile operators hide their users behind a NAT, so this
phenomenon can also occur when using a mobile connection for
connectivity to the internet.
The problem with DTLS resumption is the following:
   1. a device initiates a connection to a server using DTLS (UDP) through the NAT
   2. The keys are exchanged
   3. the device now goes to sleep or has no messages to push to the server
   4. Since the timeout in a typical NAT for a UDP connection is rather short, it is aged out
   5. the device now sends an updated value
   6. The NAT gives the device a new source port or the message even can come from an other IP address
   7. Now the server currently has now possibility to know which DTLS connection this message belongs to, so the server does not respond
   8. The device now has to wait for a timeout, possibly after numerous retries
   9. The device has to start at step 1 again (expensive)
I hope that this clarifies the situation?
/daniel
On Thu, 2016-11-03 at 17:17 -0500, Behcet Sarikaya wrote:
> > ##SELECTION_END##
-- 
Daniel Lux
Tlf: (+45)-46 922 722
Seluxit
Hjulmagervej 32B
9000 Aalborg
Denmark

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 4 Nov 2016 11:32:48 +0100

A minor fix

>  2. The keys are exchanged
The DTLS handshake establishes the keys and parameters need for the DTLS
Record Layer security protection to be turned on.

>  4. Since the timeout in a typical NAT for a UDP connection is rather

Regardless whether the device goes to sleep or not the problem arises
UNLESS the device keeps sending regular keep-alive values.

>  7. Now the server currently has now possibility to know which DTLS
>     connection this message belongs to, so the server does not respond

Because the DTLS record layer has no information in there that allows
the server-side to find the right security context other than looking at
the information found in the transport layer headers.

Consequently, DTLS discards the packet.

>> On Thu, Nov 3, 2016 at 3:39 AM, Daniel Lux <[email-masked] <mailto:[email-masked]>> wrote:
>>> discussed the DTLS resume problem. This problem occurs when a
>>> constrained device behind a NAT communicates with a server and the
>>> NAT changes the UDP source port or the IP address of the sending
>>> constrained device, while the server uses the source address and port
>>> number to identify the DTLS connection. 
>>
>>
>>> the resume problem? Kind regards Daniel -- Daniel Lux Tlf: (+45)-46
>>> 922 722 Seluxit Hjulmagervej 32B 9000 Aalborg Denmark
>>> _______________________________________________ T2TRG mailing list
>>> [email-masked] <mailto:[email-masked]>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Nov 2016 17:46:26 -0500

I guess I want to point out that this is an optimization/problem borne out of
trying to extend the lifespan of IPv4.  No NAT44 (or NAT66) means not as much
of a problem.

The IAB said some quite specific things today about doing that.
Just something to think about as you consider the amount of resources (human
time to discuss, coding time, additional space in a packet if appropriate,
code space).

**HOWEVER**, a mode that the 6tisch one-touch bootstrap situation has considered
is one where the the device is started up in a well-controlled environment.
(Faraday cage, coax replacing antenna, button or jumper pushed).  An initial
DTLS session is established *to* the constrained device, a resume token is
created on it and stored on a manufacturer or operator server.
The resume token is used as a bearer voucher for the eventual owner/operator
when the device is deployed.

AFAIK, this won't suffer from the same problem as the described in this
thread, as the constrained device would not include the source UDP/IP
in the ticket, and would likely have only a single active session to
reconnect to.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Nov 2016 17:49:09 -0500

Hannes Tschofenig <[email-masked]> wrote:
    >> 3. the device now goes to sleep or has no messages to push to the
    >> server 4. Since the timeout in a typical NAT for a UDP connection is
    >> rather short, it is aged out

    > UNLESS the device keeps sending regular keep-alive values.

Agreed.

    >> 5. the device now sends an updated value 6. The NAT gives the device a
    >> new source port or the message even can come from an other IP address

    > the server-side to find the right security context other than looking
    > at the information found in the transport layer headers.

    > Consequently, DTLS discards the packet.

I was also going to respond to say that this has nothing to do with the TLS
resume.  The problem is that DTLS is using UDP as a transport, and the DTLS
record format (unlike IPsec) does not have a clear SPI# in it, despite being
rather huge.