Hi Mark,
Thanks for your note. Some comments below...
On Wed, Mar 29, 2017 at 8:10 AM, Mark Dunn <
mark.d...@objectiveintegration.uk> 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.
>
> 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
> 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
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
