[TLS] xLS 1.3: cookie

[Mark Dunn <[e-mail]>]

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?

It seems unlikelyas it would kill 0-RTT, and I am not sure whetherit 
would reduce the workload of the server.

     ClientHello

     +pre_shared_key

     +early_data

     +...                ----->

                                 HelloRetryRequest

                        <-----   +cookie

     ClientHello

     +cookie

     +pre_shared_key

     +...                ----->

                                 ServerHello

                                 +pre_shared_key

                         <-----  +...

ClientResponse

     finished

     application Data        ----->


1b)    If (1a) is false then do you agree that the "cookie" extension 
MUST be accompanied by the "key_share" extension? Otherwisewe might be 
faced with

     ClientHello

     +key_share

     +... ----->

HelloRetryRequest

                       <-----+cookie

     ClientHello

     +cookie

     +key_share

     +...               ----->

HelloRetryRequest

<-----   +key_share

     ClientHello

     +key_share

     +...        ----->

                                 ServerHello

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

While the use of the "cookie extension" helps mitigate DOS and DOS 
amplification(ref draft-rescorla-tls-dtls13-01 section 5.1), it 
penalises the legitimate client which requires an extra round 
trip.Alsocookie does not help with a botnet attack where the bots may 
send legitimate unauthenticated requests.

For authenticatedclients a botnet DOS attack could be mitigated by 
authenticating the clientfirst.

In the worst case where the client provided an unacceptable key_share 
the Server would have to provide

     ClientHello // flight 1

     +key_share

     +signature_algorithms

     +supported_groups

     +...                ----->

                                 HelloRetryRequest // flight 2

                                 +cookie // from DTLS 1.2: HMAC(secret, 
Client-IP, Client-Parameters)

                                 +key_share(server_share)

                                 +signature_algorithms // not required 
as supplied by client

                                 +supported_groups // not required as 
supplied by client

                         <-----  {CertificateRequest}      // implied 
when key_share(server_share) is used

     ClientHello   // flight 3

     +key_share

     +cookie // this may provide state information to the server

     +...

     {Cetrificate}

     {CertificateVerify}

     {finished} // provides reachability for the client first and is 
protected by server_handshake_traffic_secret

     [application data]  ----->     // protected using keys derived from 
traffic_secret_N

                                 ServerHello // flight 4

                                 {EncryptedExtensions}

                                 {Certificate}

                                 {CertificateVerify}

                                 {Finished} // provides reachability for 
the server

                         <-----  [application data]



For authenticating clients, this would provide better defense against 
DOS, DOS amplification and require fewer round trips.