Subject: [quicwg/base-drafts] Ben Kaduk's Transport Comment 9 (#4616)

From: Lucas Pardue <[email-masked]>
Date: Wed, 06 Jan 2021 17:05:40 -0800

@kaduk said:

> Section 6.2
>
> >                                             A client MUST discard any
> > Version Negotiation packet if it has received and successfully
> > processed any other packet, including an earlier Version Negotiation
> > packet.  [...]
>
> It seems like this requirement might be too strict, in that it could
> prevent otherwise successful communication when a limited on-path
> attacker injects a Version Negotiation 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/4616

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Jan 2021 17:36:43 -0800

The working group has a strong agreement not to provide have explicit defense against attempts to disrupt of a handshake prior to completing key agreement.  This is documented in [Section 21.2](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-handshake-denial-of-service) of the document and so we don't defend against this specific style of attack.  On purpose.

We debated this (and other similar attacks) at some length and concluded that the fix would be too costly.  Both to specify and to implement.  Some people expressed interest in implementation independent, there was no consensus in the working group and those people were happy with that decision as it was interest and not commitment.

-- 
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/4616#issuecomment-755827700

---

From: kaduk <[email-masked]>
Date: Sat, 09 Jan 2021 20:42:07 -0800

I think that not providing an explicit defense against handshake disruption is fine, but flat-out prohibiting anyone from trying to make one is a stronger requirement than just not providing one.

I was reacting to the scenario where there is both a legitimate and a spoofed Version Negotiation, and the apparent prohibition against speculatively processing both and seeing if there were different results (in favor of requiring the first one that arrives to "win").  I am no longer sure that "otherwise successful communication" is accurate, though, given what we currently say to do when you get a Version Negotiation, so I am not inclined to press the point.

-- 
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/4616#issuecomment-757414614

---

From: Martin Thomson <[email-masked]>
Date: Sun, 10 Jan 2021 18:00:38 -0800

The prevailing view was that it was possible to pursue both, but those would result in a state fork and so the rules we define would apply to each fork.  Concretely, if you get two packets, you could follow each of the four possible end states to its logical conclusion with the spec rules applying to each independently.

Of course, there is an inconsistency here.  We mandate that clients dump state in response to receiving Version Negotiation, so the discard rule is basically impossible to comply with.

-- 
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/4616#issuecomment-757588182

---

From: kaduk <[email-masked]>
Date: Sun, 10 Jan 2021 23:16:49 -0800

Thank you for expounding on the previous WG discussions; the impression I got just from the text in the I-D was something different than that.  Let's close with no change.

-- 
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/4616#issuecomment-757669550

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Jan 2021 20:47:02 -0800

Closed #4616.

-- 
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/4616#event-4193967586