Subject: Re: [quicwg/base-drafts] Server-proposed connection ID (#119)

From: Martin Thomson <[email-masked]>
Date: Sun, 12 Feb 2017 16:18:10 -0800

Note: the obvious way to address this issue is to just change the connection ID.  However, that creates a problem if the new connection ID is sent with a HelloRetryRequest (i.e., stateless reject).  A client that receives a HelloRetryRequest will be unable to verify that the server actually received its packet.  A client can't know if it is reacting to an off-path attacker.  It will only learn later when its handshake falls apart.

If echoing 31 bits of entropy is sufficient, this can be addressed by requiring that the server also ACK the ClientHello.  #283 means that the server would have to have seen the randomized packet number.

-- 
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/issues/119#issuecomment-279268326

---

From: ianswett <[email-masked]>
Date: Tue, 14 Feb 2017 08:10:24 -0800

A note on mnot's summary.  This was correct when written, but since then it seems everyone is moving towards a model where the client provides a connection ID and the server replaces it.  I support this change, but I wanted to note it's different from what was agreed upon in Tokyo.

I support requiring acking the CHLO in the same packet as the HRR, as it makes the recovery doc cleaner and isn't that difficult to implement.

The HRR could also contain a new connection id in it, for use by the client.  This is what QUIC currently does for stateless rejects.

This would mean for the first full round trip, the client proposed connection id would be used, and then the connection switches to the new connection id.  In the case of a stateless reject(or version negotiation), I believe we want to use a new connection id anyway, since it's a new 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/issues/119#issuecomment-279752353

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Feb 2017 15:19:56 -0800

I don't think that we want or need to have a new connection ID in the HelloRetryRequest.  We want the server to be able to propose a new connection ID without adding a round trip, so I'm going to suggest that we just have the server include a new connection ID in the header when it answers.  That can be on the stateless reject, or when the server continues the connection (ServerHello).

Stateless reject can't really be a properly "new" connection, at least from the client perspective: the TLS handshake transcript includes the initial ClientHello, the HelloRetryRequest and second ClientHello.

-- 
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/issues/119#issuecomment-279868345

---

From: mirjak <[email-masked]>
Date: Wed, 15 Feb 2017 00:34:04 -0800

Or if you have a random packet number and a packet number echo (#269) this anyway gives you a way to verify that the server received your packet. 

-- 
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/issues/119#issuecomment-279948276

---

From: ianswett <[email-masked]>
Date: Wed, 15 Feb 2017 05:54:19 -0800

@martinthomson Ok, that's very different from how I thought stateless reject was going to work.  Does the server need to include the entire ClientHello in the source address token to allow it to be stateless, or can it send a hash of some sort?

Also, if you put the new connection ID in the HRR, why would that cost a round trip?  

Either way, I think acking the packet is sufficient entropy, so I believe that solution closes this issue.  Acking is better than packet number echo in the sense that the ack would remove the packet from flight, stop retransmissions, etc.

-- 
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/issues/119#issuecomment-280016288

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Feb 2017 09:30:18 -0800

The server can pickle hash state into the cookie.  There's some continuing discussion about the details of that in TLS, but that only really affects how easy it is to implement and the cookie size.  

It's not the source address token, that would be separate information.

Using HRR would cost an extra round trip if that was your only way to propose a new connection ID.  In the normal, happy case we would want to avoid using HRR because it imposes a round trip penalty.

-- 
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/issues/119#issuecomment-280079163