Subject: [TLS] xLS 1.3: cookie

From: Mark Dunn <[email-masked]>
Date: Wed, 29 Mar 2017 14:10:28 +0100

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.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 29 Mar 2017 09:29:58 -0500

Hi Mark,

Thanks for your note. Some comments below...

> 1a)    Should a client expect to respond to a cookie during session

Yes, it has to be ready to. As you say, it kills 0-RTT, but that's how HRR
always behaves.

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

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.

> 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

> 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
>
>     +...                ----->
>
>                                 +signature_algorithms // not required as
> supplied by client
>
>                         <-----  {CertificateRequest}      // implied when
> key_share(server_share) is used
>
>     ClientHello   // flight 3
>
>     +key_share
>
> For authenticating clients, this would provide better defense against DOS,
> DOS amplification and require fewer round trips.
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>