Folks,
Several of the remaining TLS 1.3 issues have to do with the
ClientHello/HelloRetryRequest interaction. To recap, if the
ClientHello does not contain a KeyShare with an acceptable group, the
server sends a HelloRetryRequest indicating the correct group,
and the client sends a ClientHello with the correct group:
Client Server
ClientHello
+ KeyShare -------->
<-------- HelloRetryRequest
ClientHello
+ KeyShare -------->
ServerHello
+ KeyShare
...
DTLS has a very similar mechanism where the server provides a
HelloVerifyRequest containing a cookie in order to force the client to
provide proof of routabilty at its claimed address. The client
re-sends the ClientHello with the cookie and the handshake restarts.
It seems natural to try to merge these mechanisms, but this raises
the question of whether the handshake hashes should continue through
the rejection exchange (https://github.com/tlswg/tls13-spec/issues/104).
The tension here is that you want to be able to have a stateless
rejection (to avoid DoS in the DTLS scenario) but having things
makes it much harder to analyze the handshake's resistance to
downgrade attacks.
Recently, Karthik, Martin Thomson, and I were talking and I think we've
come to a good resolution. The basic observation is that it's possible
to continue the handshake hash through the rejection exchange while
still being stateless. We are aware of two main techniques here:
- The server offloads its handshake hash state into the cookie
it provides in the HelloRetryRequest (we'll need the cookie here
in any case to support the DTLS case. The cookie obviously needs
to be cryptographically protected, but that's what you're supposed
to do for DTLS anyway
(see: https://tools.ietf.org/html/rfc6347#section-4.2.1)
- The server reconstructs the original ClientHello and HelloRetryRequest
based on the re-sent ClientHello. This is possible because there are
very strict rules about re-sent ClientHello construction
(namely: send the same ClientHello except just add a KeyShareEntry
for the indicated group). The cookie should also allow the server
to double-check this (and will also need to indicate the reason
for rejection).
Because the handshake hash is continued through the entire handshake,
it's much easier to analyze the downgrade properties. Moreover,
servers which don't need stateless reject (because there is some
other connection construct as with TLS over TCP or DTLS with
ICE) don't need either of these techniques. They can just continue
the handshake hash in the usual way.
This seems like it fulfills both imperatives, at the primary cost of
some additional complexity on servers who really care about
statelesness (the client is indifferent to the server's implementation
strategy).
If this sounds good to people, I'll work up a PR for this, but
really all it is is saying that you don't reset the hash and
then a non-normative appendix describing stateless implementation
techniques.
Thoughts? Does anyone see anything wrong with this?
-Ekr
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
