Subject: Re: [TLS] [xLS 1.3: cookie] - DTLS queries

From: Mark Dunn <[email-masked]>
Date: Wed, 19 Apr 2017 18:07:18 +0100

On 29/03/17 15:29, Eric Rescorla wrote:
> Hi Mark,
>
> Thanks for your note. Some comments below...
>
>
> On Wed, Mar 29, 2017 at 8:10 AM, Mark Dunn 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I am trying to implement cookie and finding it a little
>     underspecified.
>
>         I am using the TLS 1.3 specified in github and
>     draft-rescorla-tls-dtls13-01
>
>
>     1a)    Should a client expect to respond to a cookie during
>     session resumption?
>
>
> Yes, it has to be ready to. As you say, it kills 0-RTT, but that's how 
> HRR always behaves.
>
I understand an HRR cookie should cause an extra round trip, but in this 
case because of
         "DTLS servers SHOULD perform a cookie exchange whenever a new 
handshake is being performed"
And
         "Early data is not permitted after HelloRetryRequest."
This results in 2-RTT as the default case, is this what you intended?

>
>     1b)    If (1a) is false then do you agree that the "cookie"
>     extension MUST be accompanied by the "key_share" extension?
>
>
> If I understand you correctly, then I think this is wrong. You only 
> send key_share to correct
> the client's key_share, so if the client sent a key_share but you send 
> cookie to force
> a round-trip, then you don't send key_share, just cookie.
>
OK, does this mean a change to DTLS 1.3 figure 4?
from

Client                                             Server

ClientHello                                                 +----------+
  + key_share*                                               | Flight 1 |
  + pre_shared_key*      -------->                           +----------+

                                                             +----------+
                         <--------        HelloRetryRequest  | Flight 2 |
                                           + cookie          +----------+

to

Client                                             Server

ClientHello                                                 +----------+
  + key_share*                                               | Flight 1 |
  + pre_shared_key*      -------->                           +----------+

                                                             +----------+
                         <--------        HelloRetryRequest  | Flight 2 |
                                           + cookie          +----------+

*   + key_share* *
>
>
>
>
>     2)    I understand this is too late for TLS(only DTLS SHOULD use
>     cookies) but is there a better solution than a cookie?
>
>
> This seems like it would be a big restructure of the handshake, and 
> given the
> relatively modest use of client auth in many contexts, I don't think 
> it would probably
> be worth it.
>
> Best,
> -Ekr
>
Many infrastructure devices: smart router, smart switch, virtual switch 
and most of the IoT require a
publish / subscribe / notify pattern or an exception pattern. Do these 
not qualify?

The following use case is a publish / subscribe / notify excerpt from my 
notes, from which I have further questions.
This use case shows that while DTLS 1.3 is provably secure, it has been 
optimised to be very asymmetric in the way it delivers this security. *
*(Sorry it is not the exact format you have used in the spec.)
I have used "Accelerometer" and "Brake" in place of "Alice" and "Bob" :)

Unlike people, *things* generally do not browse the web. It is likely 
that they will be commissioned, configured and left mostly to perform 
their primary function.

Example: The *controller* configures communication between two *things*; 
an *accelerometer* and a *brake* to control wheel spin.

The *controller* initiates a three way handshake with the *accelerometer*

ClientHello ----- >

+key_share…

< ----- ServerHello

+key_share…,

{

reference to the *accelerometer’s* certificate

CertificateVerify,

Finished

}

ClientResponse ----- >

{

reference to the*controller's *certificate,

CertificateVerify,

Finished

} ,

[data:command]

< ----- [data:ack]

This establishes an ephemeral Diffie Hellman *shared key* which is used 
to encrypt the communication. The controller already knows the 
accelerometer and has cached its certificate, so does not require the 
*certificate chain* , but does require the CertificateVerify *signature* 
to authenticate the *accelerometer*. The *controller* then commands the 
*accelerometer* to *authorise* access for the *brake* to monitor it. 
Similarly, the*controller *communicates with the *brake* to command it 
to monitor the *accelerometer*. This process may provide both *things* 
with each other’s *certificates*.

The *brake *initiates a three way handshake with the *accelerometer *to 
request a subscription to a value*
*

ClientHello ----- >

+key_share…

< ----- ServerHello

+key_share…,

{

reference to the *accelerometer's *certificate,

CertificateVerify,

Finished

}

ClientResponse ----- >

{

reference to the *brake's* certificate,

CertificateVerify,

Finished

},

[data:request:subscribe]

< ----- [

Ack,

NewSessionTicket,

data:response:ack

]

The *brake* makes a request, encrypted with the *shared key,* to monitor 
the *accelerometer* for sudden acceleration.

They agree a *pre-shared key* to use on the next session. A session in 
this case is ended when either thing loses its ephemeral memory.

When the *accelerometer* needs to inform the *brake* of high 
acceleration (wheel spin)

The accelerometer uses the *shared key* to encrypt the Notification

< ----- [data:notify:value]

*
***

*Subsequent Communications **(0-RTT or Zero Round Trip Time)*

If either of the *things* loses their ephemeral memory, then they need 
to use the *pre-shared key *they agreed on earlier. This time the client 
is the *accelerometer.*

ClientHello ----- >

+pre_shared_key,

+key_share,

+early_data…

(data:notify:value)

< ----- ServerHello

+pre_shared_key,

+key_share…,

{finished…}

[data:ack]

ClientResponse ----- >

(endOfEarlyData)

{finished}

< ----- [Ack, NewSessionTicket]

*Renegotiation*

If the car is switched off then the next time it is switched on then 
full authentication is required once again (without the need for a 
certificate chain)

*Further Questions

*3) Is it true that the certificate or certificate chain are not 
required to be passed in the handshake, it is the client's ability to 
check the CertificateVerify signature against the certificate. This 
certificate may have been obtained by other means. If this is the case, 
could we have an explicit method to ask for either the certificate or 
the certificate chain rather than providing an expensive certificate 
chain by default. (I looked at raw certificates, but they do not seem to 
provide a path to root of trust)

4) Does the DDOS threat disappear if only certificate references or 
certificates are provided, removing the amplification threat and thus 
the need for a cookie?

5) I understand for pre_shared_key that we require a If we provide a 
CertificateVerify, why do we need a Finished as well?

6) In "Subsequent Communications" It was the old server, but now the new 
client that uses the pre_shared_key, what are your thoughts?

7) In TLS 1.3, i think it is implicit that a session corresponds to a 
TCP connection or similar, what are your recommendations for what 
constitutes a session in DTLS 1.3?

I am still slogging through how to create a cookie, which is an 
exceptional version of Transcript-hash (TLS section 4.4.1), which I 
still haven't figured out....

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 20 Apr 2017 08:22:51 +0200

Hi Mark,

thanks for your review.
A few remarks below.

> This results in 2-RTT as the default case, is this what you intended?

This is a very good observation. I added an issue to the tracker about
this question:
https://github.com/tlswg/tls13-spec/issues/972

It would be good to have a justification for this restriction and it
would be worthwhile to re-consider it in the DTLS specification since
the use of HRRs will be common with connection-less transport protocols.

>  + pre_shared_key*      -------->                           +----------+

Since question 1a was answered with yes I believe this question is
obsolete. Right?

>>     cookies) but is there a better solution than a cookie?

Cookies are well-established concepts for keeping servers stateless.

> publish / subscribe / notify pattern or an exception pattern. Do these

The application layer interaction has to be implemented on top of TLS/DTLS.

> The *controller* initiates a three way handshake with the *accelerometer*
It depends on what environment you are in and where the controller
actually is. However, it is quite likely that the IoT device starts the
exchange with the controller since the controller does not know what the
IP address is, when it is reachable, and whether it is even awake.

> with each other’s *certificates*.

To reduce the amount of data being exchange other specifications have
been defined, such as the TLS cached info and the client certificate
URI. I believe they would provide what you are asking for (in terms of
reference to the controllers certificate).

Additionally, note that there will be an application layer protocol on
top of the DTLS/TLS exchange to deal with application layer specific
authorization requests and their command.

> The accelerometer uses the *shared key* to encrypt the Notification

I believe you are tying to illustrate the use of a PSK here. This is
also supported in TLS in two ways:
 * First, there is a session key established at the end of the handshake.
 * Second, even if you started with a public key based authentication
you can later use PSKs with the use of the tickets.

Does this address your use case?

> to use the *pre-shared key *they agreed on earlier. This time the client

It depends on where you store your PSKs you might loose them as well and
only your long-term key is still available.

> full authentication is required once again (without the need for a

I have not seen the need for post-handshake authentication in IoT
scenarios. Could you elaborate?

> provide a path to root of trust)

Yes, there is the TLS Cached Info and the client certificate URL extension.

> certificates are provided, removing the amplification threat and thus

The problem with DDoS is two-fold:
- First, there is the amplification attack problem.
- Second, there is the resource exhaustion problem.

With certificate-based authentication you at least have the second
problem. The first problem is reduced if you do not send long messages
but a single (small) ClientHello will still lead to 5-6 messages being
sent by the server.

> CertificateVerify, why do we need a Finished as well?

The CertificateVerify demonstrates that the sender has a private key
corresponding to the certificate sent. The Finished message demonstrates
that it was able to derive the keys (key confirmation).
> client that uses the pre_shared_key, what are your thoughts?

Not sure I fully understand that scenario.

> constitutes a session in DTLS 1.3?

In DTLS 1.3 the session concept is indeed a bit loose and defined as
"An association between a client and a server resulting from a handshake."

Ciao
Hannes

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 20 Apr 2017 09:34:49 -0500

> the use of HRRs will be common with connection-less transport protocols.

Note that we currently document sending HRR as a way for a server to
reject early data without having to do trial decryption to determine the
end of early data (since the outer content-type is meaningful for the
ClientHello2).  I expect there will be some situations where servers do
not want to implement trial decryption, so removing this functionality
without replacement seems ill-advised.

-Ben

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 21 Apr 2017 09:44:38 +0200

Hi Ben,

thanks for your remark.
I don't think that this is an issue in DTLS since the epoch field
provides additional information to properly select the correct key.

Ciao
Hannes