Subject: Re: [quicwg/base-drafts] The QUIC-TLS draft should define anti-forgery limits for packet lengths up to 2^16 (#3701)

From: Lars Eggert <[email-masked]>
Date: Mon, 21 Sep 2020 04:58:55 -0700

Without a PR, this will stay as is...

-- 
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/3701#issuecomment-696068209

---

From: David Schinazi <[email-masked]>
Date: Mon, 21 Sep 2020 17:40:11 -0700

Leaving things as-is is unsafe, as the current document allows sending QUIC packets of size 2^15 without providing bounds required for the security properties promised by the protocol. If we don't have anyone willing to the analysis for 2^16 (I don't consider myself competent enough to get this right), then we should disallow sending or receiving QUIC packets longer than 2^14. Otherwise we're shipping a protocol that is not safe.

-- 
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/3701#issuecomment-696453858

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Sep 2020 16:02:08 -0700

So I talked this over with @chris-wood and we both agree that this is not unsafe enough to block publication based on:

> Where packets might be larger than 2^14 bytes in length, smaller limits might be needed.

Getting this right is hard enough that I'm concerned that we'll make another mistake.  The number of mistakes we made already is enough that I don't want to put this in a spec without multiple rounds of checking.

@MikeBishop points out that a change in targets also changes some MUST-level requirements and so wouldn't be a purely editorial change, so I'm going to remove the "editorial" tag and suggest that we just not take 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/issues/3701#issuecomment-698631070

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 24 Sep 2020 16:14:41 -0700

Sounds like a nice to have that would benefit from more time and experience. Marking as "future-version" for later consideration but otherwise closing this to clear our landing path.

-- 
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/3701#issuecomment-698634662

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 24 Sep 2020 16:14:44 -0700

Closed #3701.

-- 
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/3701#event-3805408686

---

From: David Schinazi <[email-masked]>
Date: Thu, 24 Sep 2020 18:13:37 -0700

Hi @LPardue @larseggert @mnot, did I miss a recent change to our process? Since when are we closing non-editorial issues without a call for consensus?

-- 
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/3701#issuecomment-698666971

---

From: ianswett <[email-masked]>
Date: Thu, 24 Sep 2020 18:25:00 -0700

I believe the process says that design issues cannot be closed without a call for consensus and this was never marked as a design issue.

@mnot created a flowchart at some point, but I'm failing to find it.

Given the difficulty of deploying even 4k packets, I don't foresee this being a practical problem in the near future.

-- 
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/3701#issuecomment-698669604

---

From: David Schinazi <[email-masked]>
Date: Thu, 24 Sep 2020 18:38:00 -0700

The flow chart is [here](https://github.com/quicwg/base-drafts/blob/master/workflow.png). Closing an issue that's marked neither editorial nor design isn't a scenario that's allowed according to that diagram.

-- 
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/3701#issuecomment-698672768

---

From: ekr <[email-masked]>
Date: Thu, 24 Sep 2020 19:04:58 -0700

I agree with David that this doesn't seem like the right resolution. I also agree with MT that we should not attempt to adjust the limits for bigger packets now.

Given Ian's comment I think the correct resolution is to simply forbid packets > 2^14. If/when someone does the analysis for larger packet sizes, that document can simply lift this restriction and replace it with whatever the new rules are. This is explicitly contemplates in S 6.6. "Future analyses and specifications MAY relax confidentiality or integrity limits for an AEAD."

-- 
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/3701#issuecomment-698679079

---

From: ekr <[email-masked]>
Date: Thu, 24 Sep 2020 20:07:10 -0700

Hmm.. Thinking about this a little more
We can certainly prohibit *sending* > 2^14 packets, but we if we prohibit receiving it, then we'll need an extension to let you send them. And if we don't, then the receiver will not be able to properly enforce the limits on 2^16. So, maybe not so easy...

-- 
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/3701#issuecomment-698694764

---

From: David Schinazi <[email-masked]>
Date: Thu, 24 Sep 2020 20:57:15 -0700

We could solve this by slightly tweaking the definition of the `max_udp_payload_size` transport parameter.

OLD TEXT:
> The default for this parameter is the maximum permitted UDP payload of 65527. Values below 1200 are invalid.

NEW TEXT:
> The default for this parameter is 16384. Values below 1200 are invalid, values above 16384 are invalid.

If/when someone ever figures out anti-forgery limits for packet sizes above 16384, they can define an extension that negotiates that feature.

-- 
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/3701#issuecomment-698706048

---

From: ekr <[email-masked]>
Date: Thu, 24 Sep 2020 21:10:13 -0700

I had forgotten about this parameter. I don't think we even need an extension. We say:

> You MUST NOT send max_udp_payload_size > 16384. If you receive max_udp_payload_size > 16384 you MUST treat it as 16384.

Then if we figure out new anti-forgery limits we remove these MUSTs.

Only new implementations will send max_udp_payload_size > 16384 and only if both implementations are new will they send packets > 16384. That means that (1) sending implementations will enforce the right AEAD limits (2) only implementations which know about the new limits will offer max_udp_payload_size > 16384 and they can just reject longer packets out of hand which means that they don't contribute to the forgery limit.

-- 
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/3701#issuecomment-698709000

---

From: David Schinazi <[email-masked]>
Date: Thu, 24 Sep 2020 22:10:26 -0700

That sounds good to me.

-- 
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/3701#issuecomment-698723133

---

From: Lars Eggert <[email-masked]>
Date: Thu, 24 Sep 2020 23:25:01 -0700

I wold like more people to take a look at this. To me personally, this seems like a simple enough change, but it is a design change...

Since we **really** want to start IETF LC today (because the longer we delay, the more editorial issues are being opened again, perpetuating the cycle), I propose we convert this issue to an IETF LC issue and resolve it together with anything else that gets raised during 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/issues/3701#issuecomment-698746338

---

From: ianswett <[email-masked]>
Date: Fri, 25 Sep 2020 06:57:38 -0700

Reducing the max packet size in QUIC v1 is fine by me, given I don't expect to exceed 16384 bytes.

-- 
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/3701#issuecomment-698944158

---

From: David Schinazi <[email-masked]>
Date: Fri, 25 Sep 2020 08:32:56 -0700

@larseggert making this an IETF LC issue is fine if you prefer it that way. Can you please reopen this issue and replace the "future-version" GitHub tag with "ietf-lc"?

-- 
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/3701#issuecomment-698997279

---

From: Lars Eggert <[email-masked]>
Date: Fri, 25 Sep 2020 08:44:19 -0700

Reopened #3701.

-- 
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/3701#event-3808326014

---

From: Lars Eggert <[email-masked]>
Date: Fri, 25 Sep 2020 08:44:56 -0700

Done. I hope we can resolve this quickly.

-- 
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/3701#issuecomment-699003871

---

From: David Schinazi <[email-masked]>
Date: Fri, 25 Sep 2020 09:23:58 -0700

Thanks. I hope so as well. Would you like me to send a PR or should I wait for IETF LC to start?

-- 
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/3701#issuecomment-699024145

---

From: Lars Eggert <[email-masked]>
Date: Fri, 25 Sep 2020 10:12:09 -0700

Let's wait for some more comments on the issue. The editors were swamped.

-- 
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/3701#issuecomment-699047700

---

From: Martin Thomson <[email-masked]>
Date: Mon, 28 Sep 2020 15:19:50 -0700

After thinking about this a lot, I prefer not to do anything.  For several reasons, but mostly because I think that a mechanical protection is an overreaction to this situation.

The target limits are arbitrary.  The degradation here is *at worst* an increase in attacker advantage from 2^-57 to 2^-53.  That's for CCM.  The GCM and Poly1305 numbers scale linearly, so the change is to 2^-55.

I could see a way to sharpen the text, but mandating use of the UDP size limit to do this seems unnecessary.  Suggesting that usage - for the paranoid - would be OK.

-- 
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/3701#issuecomment-700313973

---

From: David Schinazi <[email-masked]>
Date: Mon, 28 Sep 2020 15:25:34 -0700

If you're fairly confident in your analysis that 2^16 byte packets are safe given certain bounds, can we instead put those bounds in the spec? If you're not confident in said bounds, then I'm uncomfortable shipping a protocol whose security bounds we are not confident in. At the end of the day, either we know the bounds or we don't, I'm not understanding what a middle-ground looks like here.

-- 
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/3701#issuecomment-700316012

---

From: ekr <[email-masked]>
Date: Tue, 29 Sep 2020 16:18:18 -0700

I think I am with David here.

Specifically: I think the document should provide a traffic limit and an analysis that those limits provide security at least at a given level.  It seems like we have three choices (1) restrict the packet size (2) lower the traffic limits (3) provide an analysis with a weaker guarantee, given that as MT points out, the guarantee is somewhat arbitrary

-- 
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/3701#issuecomment-701041703