Subject: [quicwg/base-drafts] Do we still need Retry packets? (#1233)

From: Marten Seemann <[email-masked]>
Date: Sun, 18 Mar 2018 23:04:43 +0000 (UTC)

After the recent header changes, there's no need for a Retry packet type any more. The server could send its HRR in a normal Handshake 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/1233

---

From: Subodh Iyengar <[email-masked]>
Date: Sun, 18 Mar 2018 16:27:19 -0700

ya i agree with this. The TLS stack on the client already knows whether it is a stateful or a stateless retry, and can act accordingly. Serializing the information the client already knows into a frame type is redundant and error prone.

cc @mcmanus 

-- 
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/1233#issuecomment-374066166

---

From: MikkelFJ <[email-masked]>
Date: Sun, 18 Mar 2018 16:29:15 -0700

It depends - the frame type may help to decide between different CID's which helps lookup and reduce conflicts - but I'm not sure it is an issue in this direction.

-- 
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/1233#issuecomment-374066406

---

From: ianswett <[email-masked]>
Date: Sun, 18 Mar 2018 17:27:40 -0700

I can't come up with a clear reason for them.  The crypto handshake is going to have to indicate that the reset is stateful or stateless, and the transport is going to have to respond accordingly, so I haven't been able to determine what value the extra packet type provides.

-- 
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/1233#issuecomment-374070626

---

From: ekr <[email-masked]>
Date: Mon, 19 Mar 2018 08:06:10 +0000 (UTC)

@siyengar: How does the client know whether it's a stateful or stateless retry? They look the same in TLS. It's just an HRR. It's only the server that knows

-- 
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/1233#issuecomment-374129885

---

From: ekr <[email-masked]>
Date: Mon, 19 Mar 2018 08:09:23 +0000 (UTC)

Oh, I see you're going to claim it has a cookie or it doesn't. But that's not actually the same thing, because you might be using the cookie just to require a proof of reachability as an anti-crypto DoS mitigation

-- 
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/1233#issuecomment-374130500

---

From: Subodh Iyengar <[email-masked]>
Date: Mon, 19 Mar 2018 09:45:52 +0000 (UTC)

@ekr I think the client shouldn't know what the difference is between those two cases and should react the same way. For the clients it's a stateless reset either way.  My thought here is that the TLS layer provides an API to say whether or not the message that was received was a stateless reset.

Generally I'm leaning towards the principle that if an endpoint can know about something via an API, we shouldn't need to signal that in a framing layer.

-- 
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/1233#issuecomment-374154641