Subject: Re: [Dtls-iot] Session resumption (was: [TLS] New draft: draft-rescorla-tls13-new-flows-01)

From: Zach Shelby <[email-masked]>
Date: Thu, 13 Mar 2014 21:40:10 -0700

Hi Klaus,

I know you're working to put together a draft on this, but I wanted to resurface this thread in case others have some more input for you.

Looking our deployments and use cases for DTLS, I can't find a use for either renegotiation or resumption (as defined today).

We do however have the problem of dynamic IP addresses changing fairly often on mobile constrained endpoints, sometimes in-between even just single CoAP notifications. It would be very useful if DTLS 1.3 would have a mechanism to deal with that without requiring a new handshake each time the IP address changes. Some kind of mechanism to include the Session ID after the IP address has changed for example.

Zach

On Feb 25, 2014, at 6:06 AM, Klaus Hartke <[email-masked]> wrote:

> Eric Rescorla wrote:
>> - There is no currently defined support for any kind of resumption.
>> We need to decide if resumption is still an important feature in light
>> of the trend towards more PFS and faster processors.  I'm particularly
>> looking for input from the IoT/DICE guys here.
>
> I'm not really sure what's being done in existing deployments, but I'd
> be inclined to say that session resumption is not really needed.
>
> The feature allows a client to create a session and get a Session ID.
> This Session ID can be used by the client to duplicate the session or
> to later resume the previous session. The server has to store the
> session state with the Session ID in a cache.
>
> - Duplicate the session: I'd assume that a constrained node typically
> maintains only one session to a given destination. For example, with
> CoAP a session can be used for as many requests as needed; CoAP does
> not need a new session for every request.
>
> - Resume a previous session: I'm not exactly sure what a client should
> do when it has established a session but hasn't used it for a while.
> For example, if the client has created a session to make a CoAP
> request and later wants to make another request, should it first
> resume the session? Or just try to use it, get an alert, and then
> resume it? Or try to use it, get an alert, and create a new session?
> I'd say that the server either has the session state still (then the
> client should be able to make the request right away without resuming
> the session) or it doesn't (then the client has to create a new
> session).
>
> Are there other use cases?
> Are my assumptions valid?
> Am I missing something?
> What's implemented in existing IoT DTLS deployments?
>
> Best regards,
> Klaus
>
>
>
> ---------- Forwarded message ----------
> From: Eric Rescorla <[email-masked]>
> Date: 19 February 2014 21:40
> Subject: [TLS] New draft: draft-rescorla-tls13-new-flows-01
> To: "[email-masked]" <[email-masked]>
>
>
> Folks,
>
> I have prepared a new version of the TLS 1.3 flows document which
> should appear in the repository shortly and in the meantime can be
> found at:
>
> https://github.com/tlswg/tls13-spec/blob/master/draft-rescorla-tls-1.3.txt
>
> This version fleshes out a "recommended" set of flows:
>
> - 2-RTT where the client has no knowledge of the
>  server's capabilities.
>
> - 1-RTT where the client knows the server's semi-permanent
>  DHE/ECDHE key pair.
>
> - 0-RTT where the client and the server have shared anti-replay
>  state.
>
> There are still a number of open issues, but this should be clear
> enough to see the direction I am trying to go. These flows are
> structured so that the 1-RTT case is the base case with the 2-RTT and
> 0-RTT versions being variants of the basic 1-RTT handshake. All
> variants encrypt the client extensions that are not required
> to define the cryptographic processing (e.g., SNI is encrypted
> but curve negotiation is not).
>
> I think the high order bit here is whether we want to have
> encrypted SNI, because that dictates the position of the DHE
> exchanges with respect to the server's messages.
>
> There are three options here:
>
> - Never
> - Sometimes
> - Always
>
> The flows in this draft take the position of "Always" which is
> simple. "Never" is actually simpler. "Sometimes" is the most
> complicated.  There are two cases where we could shave off latency if
> we were willing to disclose the SNI to passive attackers (and in cases
> where the client and server have never talked before.) My sense of
> recent discussion is that people feel it's important to have modes
> that protect SNI even if those are not the only modes. However, that
> means that if we want to have non-SNI protecting modes, they are
> additional complexity. Please let me know if I have misread the WG
> here.
>
>
> Here are some other things to keep in mind as you read the document.
>
> - Per my sense of the list, I have totally removed static RSA.  If
> people strongly object to that, please speak up and let me know.
>
> - There has been no real security analysis of this material other than
> at the hand-wavy level. We clearly need that, but the first thing we
> need is to be clear on whether this is approximately the right set of
> points in the complexity/performance/privacy tradeoff space and then
> make sure that the security properties are correct. So, if you see
> something that looks wrong or even grievously wrong, don't panic (but
> do point it out).
>
>
> - There is no currently defined support for any kind of resumption.
> We need to decide if resumption is still an important feature in light
> of the trend towards more PFS and faster processors.  I'm particularly
> looking for input from the IoT/DICE guys here.
>
> - We will probably need to work out some of the details for DTLS, but
> I wanted to get TLS nailed down first.
>
> - We also need to do some work on the symmetric crypto, e.g., to make
> encrypt-then-MAC the default, perhaps to deprecate some ciphers,
> compression, etc. I haven't forgotten that, but I want to deal with
> the handshakes first.
>
> - As before, this incorporates ideas from a lot of different people
> (and many times the same idea from different people). If you think
> you should acknowledged in the text and/or acknowledgements
> differently, please let me know.
>
> Thanks and comments welcome
> -Ekr
>
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot
>

Zach Shelby
Director of Technology
ARM Internet of Things BU
www.arm.com
mobile: +1 (408) 203-9434
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/

-- 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.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

---

From: Francisco Vidal Meca <[email-masked]>
Date: Fri, 14 Mar 2014 08:03:05 +0100

Dear all,

Not long time ago I was looking what options were available to support DTLS
IP change without requiring a new handshake. That led me to a DTLS Mobility
paper [1] using the Hearbeat Extension [2] and done by folks from Münster
and Duisburg-Essen University (CCed) which might just what Zach is looking
for.

Regards,
Francisco

[1] http://dx.doi.org/10.1007/978-3-642-25959-3_33
[2] http://tools.ietf.org/html/rfc6520

2014-03-14 5:40 GMT+01:00 Zach Shelby <[email-masked]>:

> Hi Klaus,
>
> I know you're working to put together a draft on this, but I wanted to
> resurface this thread in case others have some more input for you.
>
> Looking our deployments and use cases for DTLS, I can't find a use for
> either renegotiation or resumption (as defined today).
>
> We do however have the problem of dynamic IP addresses changing fairly
> often on mobile constrained endpoints, sometimes in-between even just
> single CoAP notifications. It would be very useful if DTLS 1.3 would have a
> mechanism to deal with that without requiring a new handshake each time the
> IP address changes. Some kind of mechanism to include the Session ID after
> the IP address has changed for example.
>
> Zach
>
> -- 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.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No:  2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No:  2548782
>

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Fri, 14 Mar 2014 08:52:31 +0000

...snipped...
> Some kind of mechanism to include the Session ID
> after the IP address has changed for example.

Just to add to that, sometimes the constrained endpoint may not be even aware of the IP or port change if behind a NAT. Although Heartbeat can try to maintain the port assignment with quite some data usage, if a large number of devices are present, the middle-box has to at some point clear up ports and reassign to others breaking the IP/port combination. It would be nice to have a SessionID within the record layer that identifies the session with the endpoint without resorting to the  IP/port combination to retrieve the session.

Sandeep

> -----Original Message-----
> From: dtls-iot [mailto:[email-masked]] On Behalf Of Zach Shelby
> Sent: Friday, March 14, 2014 5:40 AM
> To: Klaus Hartke
> Cc: [email-masked]
> Subject: Re: [Dtls-iot] Session resumption (was: [TLS] New draft: draft-
> rescorla-tls13-new-flows-01)
>
> Hi Klaus,
>
> Looking our deployments and use cases for DTLS, I can't find a use for either
> renegotiation or resumption (as defined today).
>
> mechanism to deal with that without requiring a new handshake each time
> the IP address changes. Some kind of mechanism to include the Session ID
> after the IP address has changed for example.
>
> Zach
>
> >> We need to decide if resumption is still an important feature in
> >> light of the trend towards more PFS and faster processors.  I'm
> >> particularly looking for input from the IoT/DICE guys here.
> >
> > - 2-RTT where the client has no knowledge of the  server's
> > capabilities.
> >
> > - 1-RTT where the client knows the server's semi-permanent  DHE/ECDHE
> > key pair.
> >
> > variants encrypt the client extensions that are not required to define
> > the cryptographic processing (e.g., SNI is encrypted but curve
> > negotiation is not).
> >
> > I think the high order bit here is whether we want to have encrypted
> > SNI, because that dictates the position of the DHE exchanges with
> > respect to the server's messages.
> >
> > The flows in this draft take the position of "Always" which is simple.
> > "Never" is actually simpler. "Sometimes" is the most complicated.
> > There are two cases where we could shave off latency if we were
> > willing to disclose the SNI to passive attackers (and in cases where
> > the client and server have never talked before.) My sense of recent
> > discussion is that people feel it's important to have modes that
> > protect SNI even if those are not the only modes. However, that means
> > that if we want to have non-SNI protecting modes, they are additional
> > complexity. Please let me know if I have misread the WG here.
> >
> >
> > (and many times the same idea from different people). If you think you
> > should acknowledged in the text and/or acknowledgements differently,
> > please let me know.
> >
> 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.
>
> Registered in England & Wales, Company No:  2557590 ARM Holdings plc,
> Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in
> England & Wales, Company No:  2548782
>

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.