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

[Hannes Tschofenig <[e-mail]>]

Hi Mark,

thanks for your review.
A few remarks below.


On 04/19/2017 07:07 PM, Mark Dunn wrote:
> 
> 
> 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
>> <[e-mail]
>> <mailto:[e-mail]>> 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?

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.

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

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


>>
>>
>>     2)    I understand this is too late for TLS(only DTLS SHOULD use
>>     cookies) but is there a better solution than a cookie?
>>

Cookies are well-established concepts for keeping servers stateless.

>>
>> 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 application layer interaction has to be implemented on top of TLS/DTLS.

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

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

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

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?

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

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

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

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

> 
> *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)

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

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

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.

> 
> 5) I understand for pre_shared_key that we require a If we provide a
> 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).
> 
> 6) In "Subsequent Communications" It was the old server, but now the new
> client that uses the pre_shared_key, what are your thoughts?

Not sure I fully understand that scenario.

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

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

> 
> 
> 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....
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls