Subject: [quicwg/base-drafts] Source address token (#120)

From: Martin Thomson <[email-masked]>
Date: Wed, 04 Jan 2017 02:18:55 -0800

I'm on the top of a large stack of changes now, and approaching saturation.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Big endian
  * Define version negotiation more thoroughly
  * Reserve space
  * not off
  * Add definition of transport parameters to -transport
  * Rewrite the section on source address tokens for TLS

-- File Changes --

    M draft-ietf-quic-transport.md (425)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/120.patch
https://github.com/quicwg/base-drafts/pull/120.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/120

---

From: Martin Thomson <[email-masked]>
Date: Wed, 04 Jan 2017 02:46:32 -0800

@martinthomson pushed 1 commit.

7eb297c  Fix dead reference

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/120/files/4a426bbba65e52f25ec2e1bff19112b520d44eff..7eb297c08e8831b94c4849b3b6246bc093a4bd28

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Jan 2017 16:37:16 -0800

I just split this from the transport parameters PR.  It has similar issues though with respect to maintaining the crypto handshake as an abstraction.

If we agree that the crypto handshake is responsible for providing this functionality, I could move the text to the TLS draft in its entirety.  But I'm not sure if that makes sense.  I would rather keep it in the transport doc, but that would either be quite a lot of work to maintain the abstraction.  As I've said before, I don't believe that the abstraction has any value, so I'm probably just showing my prejudices (c.f., YAGNI).

-- 
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/120#issuecomment-271743041

---

From: janaiyengar <[email-masked]>
Date: Wed, 11 Jan 2017 22:07:53 -0800

janaiyengar commented on this pull request.

As mentioned on the mailing list, I'm in favor of a non TLS-specific resolution here. This text moves it out of transport and moves it into TLS. The text already describes how an STK is to be used, and it's largely a server-specific thing. I don't see a reason to change this, since it's also what TFO does.

-- 
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/120#pullrequestreview-16294290

---

From: ianswett <[email-masked]>
Date: Thu, 12 Jan 2017 08:45:54 -0800

ianswett commented on this pull request.

I like the clarifications in how this will work, and I think it'd be relatively straightforward to make the transport draft not depend on TLS in this case.

> +describe/reference how this size is selected).  This allows a server to send a
+similar amount of data without validating ownership of an address (TBD: provide
+limits on what amount of amplification is enough).
+
+A server eventually confirms that a client has received its messages when the
+cryptographic handshake successfully completes.  This might be either because
+the server wishes to avoid the computational cost of completing the handshake,
+or it might be that the size of the packets that are sent during the handshake
+is too large.  This is especially important for 0-RTT, where the server might
+wish to provide application data traffic - such as a response to a request - in
+response to the data carried in the early data from the client.
+
+To send additional data prior to completing the cryptographic handshake, the
+server then needs to validate that the client owns the address that it claims.
+
+Two tools are provided by TLS to enable validation of client source addresses:

I think it would read well to move these paragraphs to the TLS doc and title the section "Source Address Tokens using the cookie extension", and then cite the source address token section in the transport doc, once it's moved.

> @@ -1133,27 +1133,6 @@ sets available to a server one-round trip earlier than parameters that are
 carried in QUIC packets.  This document does not define that extension.

-## Source Address Validation {#source-address}

With some massaging, I think this text should be moved to the bottom of the Proof of Source Address Ownership section in the transport doc.

> +describe/reference how this size is selected).  This allows a server to send a
+similar amount of data without validating ownership of an address (TBD: provide
+limits on what amount of amplification is enough).
+
+A server eventually confirms that a client has received its messages when the
+cryptographic handshake successfully completes.  This might be either because
+the server wishes to avoid the computational cost of completing the handshake,
+or it might be that the size of the packets that are sent during the handshake
+is too large.  This is especially important for 0-RTT, where the server might
+wish to provide application data traffic - such as a response to a request - in
+response to the data carried in the early data from the client.
+
+To send additional data prior to completing the cryptographic handshake, the
+server then needs to validate that the client owns the address that it claims.
+
+Two tools are provided by TLS to enable validation of client source addresses:

I don't the ticket should be used for proof of source address, since by itself it's not sufficient proof and we already have the cookie extension for that.

-- 
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/120#pullrequestreview-16398997

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Jan 2017 16:24:15 -0800

martinthomson commented on this pull request.

So I admit that I don't understand what @janaiyengar has in mind, but if you wanted to use these mechanisms, you could.  If you ALSO wanted to keep the logical split, then you say "the crypto handshake is responsible for performing source address validation" and then we shuffle things around.

I didn't recognize that option when I originally put this together.  See the mailing list thread for more.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Jan 2017 16:26:41 -0800

The ticket would only be used for 0-RTT.  You don't get to use the cookie extension for the first ClientHello.  That's a TLS limitation, we don't have a mechanism for providing a cookie for use in a future connection.  Nor do we need one because that is something that the session ticket can be used for.

---

From: Erik Kline <[email-masked]>
Date: Mon, 16 Jan 2017 00:05:28 -0800

Can this work in such a way that a QUIC connection (same connID) should survive, for example, a client rotating IPv6 temporary addresses multiple times mid-connection?

-- 
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/120#issuecomment-272796346

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Jan 2017 17:01:34 -0800

Maybe.  Whether the server insists on verifying an address will depend on the server.  Since the primary concern seems to be packet reflection, the server might be OK with clamping its send rate after seeing a change in the remote address.

What this does NOT provide is the ability for the server to insist on the client proving that it has seen packets at the new address.  That's a problem because QUIC doesn't include any innate proof of possession mechanism.  A client can pretend to have seen packets by generating an ACK, but it can't prove to have received them.

I've opened #161 to track this.

-- 
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/120#issuecomment-272995622

---

From: Victor Vasiliev <[email-masked]>
Date: Mon, 23 Jan 2017 16:00:15 -0800

I've mentioned this [on the mailing list](https://www.ietf.org/mail-archive/web/quic/current/msg00908.html), but I think I should mention it here too, so it does not get lost.  We should really understand how source address validation interacts with stateless rejects if we intend to support them.

-- 
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/120#issuecomment-274657861

---

From: ekr <[email-masked]>
Date: Mon, 23 Jan 2017 16:58:56 -0800

I think the high order question is that we have to decided if this is something that belongs in transport or in the security document. I would have thought the latter, but...

-- 
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/120#issuecomment-274668516