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

[Mark Dunn <[e-mail]>]

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?

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