On Wed, Oct 21, 2015 at 11:13 AM, Short, Todd <tsh...@akamai.com> wrote:
> I like the idea. If the functionality is to be merged, perhaps harmonizing > the names and contents of the messages (if possible)? > Yes. My plan is to name it HelloRetryRequest and get rid of HelloVerifyRequest. -Ekr > -Todd Short > // tsh...@akamai.com > // "One if by land, two if by sea, three if by the Internet." > > On Oct 21, 2015, at 1:32 PM, Eric Rescorla <e...@rtfm.com> 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=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=qs-tzs_SwwiU6AH8Y7_q_TnVqYX4ruwLo5qqkgP8HDw&s=o3UsBAmOLmYeA_GnNYIEo3Ila7mxSbS5EkfOOuVR4dY&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=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=qs-tzs_SwwiU6AH8Y7_q_TnVqYX4ruwLo5qqkgP8HDw&s=FqKoPI3ZlKRELrbW0Jr1_9Vs29f-gFLX0bVRoOy3rJk&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? > -Ekr > _______________________________________________ > 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
