On 10/21/2015 12:32 PM, Eric Rescorla wrote: > 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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls13-2Dspec_issues_104&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=ixsUSZ7qRqak0aUyXIFg-hbcXSe9ew3ZditMZBPS3dU&s=dDAwXMVbdm5TPHBOtcEHi49G8ja7gy3s2EcAqUg9La8&e=>). > 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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6347-23section-2D4.2.1&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=ixsUSZ7qRqak0aUyXIFg-hbcXSe9ew3ZditMZBPS3dU&s=cEa44t6zPucquN3jUqQvxlC8-wwzKckAc4Itu1pwyps&e=>) > > - 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? >
It sounds like a good plan. The only thing that comes to mind is whether a server might want to use encrypted (and MACd) serialized state instead of an HMAC'd blob for the cookie where it would have to reconstruct state from the re-sent ClientHello. (It should be easy to have text that allows for either case; I just wanted to mention it as a possibility.) -Ben
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
