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