[TLS] HelloRetryRequest and stateless reject

Eric Rescorla <ekr@rtfm.com> Wed, 21 October 2015 17:33 UTC

MIME-Version: 1.0
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 21 Oct 2015 10:32:59 -0700
Message-ID: <CABcZeBOxiK90WYJiTwH4dN6aqN9sBYCZSg4pv=RTYB859Ybb_g@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114e488a665b340522a0c74b"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/7rLQEHrqKaYo7u31iNBNsPI_OVg>
Subject: [TLS] HelloRetryRequest and stateless reject
Precedence: list

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

Re: [TLS] HelloRetryRequest and stateless reject Short, Todd
[TLS] HelloRetryRequest and stateless reject Eric Rescorla
Re: [TLS] HelloRetryRequest and stateless reject Benjamin Kaduk
Re: [TLS] HelloRetryRequest and stateless reject Eric Rescorla
Re: [TLS] HelloRetryRequest and stateless reject Eric Rescorla
Re: [TLS] HelloRetryRequest and stateless reject Ilari Liusvaara
Re: [TLS] HelloRetryRequest and stateless reject Martin Thomson
Re: [TLS] HelloRetryRequest and stateless reject Ilari Liusvaara