Source address token

[martinthomson]

This redefines the techniques that a server employs for verifying that a client owns its address in terms of TLS constructs.

One thing that doesn't survive this translation is the ability for a server to propose a new connection ID. I've opened #119 to track that. I removed some other TODOs, for which I've opened #118 and #117 as well.

I'm on the top of a large stack of changes now, and approaching saturation. Read #122 before proceeding with this one.

Update: I think that I understand SCUP now, in which case this closes #117.

[martinthomson]

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).

[janaiyengar]

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.

[ianswett]

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.

[ianswett]

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.

[ianswett]

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.

[martinthomson]

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.

[ianswett]

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.

[martinthomson]

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.

[ekline]

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?

[martinthomson]

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.

[vasilvv]

I've mentioned this on the mailing list, 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.

[ekr]

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...