Subject: [quicwg/base-drafts] Address validation is stateless reject (#482)

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Apr 2017 22:47:38 -0700

We already have enough text on how to tell a client to go away and come back.
But we don't really say how a server might do that statelessly.  Add a small
bit of text on that and we're done.

Closes #60
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/482

-- Commit Summary --

  * Address validation is stateless reject

-- File Changes --

    M draft-ietf-quic-tls.md (4)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/482.patch
https://github.com/quicwg/base-drafts/pull/482.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/482

---

From: ekr <[email-masked]>
Date: Fri, 28 Apr 2017 00:07:46 -0700

ekr commented on this pull request.

> @@ -1058,6 +1058,10 @@ validation was not requested originally.  In such cases, the cookie extension
 could either be absent or it could indicate that an address validation token is
 not present.
 
+A server can use the cookie extension to store all state necessary to continue
+the connection.  This allows a server to avoid committing state for clients that
+have unvalidated source addresses.
+

This works, though I think you should be clearer about how you pickle that information (self-encrypted AEAD).

However, if we're in the business of telling people what to do, we actually should document both this technique and the CH...SFIN, NST, RST technique that davidben and victor described.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/482#pullrequestreview-35289207

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Apr 2017 19:21:44 -0700

Offline, Jānis Čoders pointed out that we aren't very clear about what stream offset you expect on the second ClientHello.  I need to update to include a reminder about that too.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/482#issuecomment-298275262

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Apr 2017 19:59:07 -0700

martinthomson commented on this pull request.

I think that I'll leave the tricks for another PR.  I'm not convinced that the trick will work.  It will always require at least two packets because NST and CONNECTION_CLOSE require packet protection (I suppose you might argue that is more reason to add a new cleartext+encrypted packet type).  Then there is the size of the certificate.  It's more computation, more amplification factor, and all we get is one round trip less delay.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/482#discussion_r114094419

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Apr 2017 19:59:36 -0700

@martinthomson pushed 1 commit.

9cf713c  Expand description

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/482/files/925200694d7e523112e979c8f0c326e7eb3d8294..9cf713cfc2ad803ce7c39253bfc0bc58b87d32bc

---

From: janaiyengar <[email-masked]>
Date: Sun, 30 Apr 2017 22:25:49 -0700

janaiyengar commented on this pull request.

> @@ -1059,6 +1059,27 @@ could either be absent or it could indicate that an address validation token is
 not present.

+### Stateless Address Validation
+
+A server can use the cookie extension to store all state necessary to continue

add citation for "the cookie extension"

+A server can use the cookie extension to store all state necessary to continue
+the connection.  This allows a server to avoid committing state for clients that
+have unvalidated source addresses.
+
+For instance, a server could use a statically-configured key to encrypt the
+information that it requires and include that information in the cookie.  In
+addition to address validation information, a server that uses encryption also
+needs to be able recover the hash of the ClientHello and its length, plus any
+information it needs in order to reconstruct the HelloRetryRequest.
+
+A client proceeds as though the server were stateful.  It constructs a second
+ClientHello and sends it following the initial ClientHello.  Note that this
+means a server that doesn't maintain state between the intial and second
+ClientHello will receive the second ClientHello in STREAM frames with a non-zero
+offset.  The resulting gap in the received stream data needs to be ignored and

I don't think this hack of delivering bytes out of order works... how is a server to know that there aren't lost packets?

Alternatively, a server can send a new connection ID for the client to use for the next leg of the connection. That would be cleaner, and wouldn't need this hack of delivering bytes out of order to TLS.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/482#pullrequestreview-35540495