Original text:
reaching a state where key updates are not possible. For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit <del> is 2^25 encrypted packets; see gcm-bounds.  For </del>  AEAD_CHACHA20_POLY1305, the confidentiality limit is greater than the number of possible packets (2^62) and so can be disregarded.  For <del> AEAD_AES_128_CCM, the confidentiality limit is 2^23.5 encrypted </del>  packets; see ccm-bounds.  Applying a limit reduces the probability that an attacker can distinguish the AEAD in use from a random permutation; see AEBounds, ROBUST, and GCM-MU. AEAD_LIMIT_REACHED and not process any more packets. For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the integrity limit is <del> 2^54 invalid packets; see gcm-bounds.  For AEAD_CHACHA20_POLY1305, </del>  the integrity limit is 2^36 invalid packets; see AEBounds.  For <del> AEAD_AES_128_CCM, the integrity limit is 2^23.5 invalid packets; see </del>  ccm-bounds.  Applying this limit reduces the probability that an attacker can successfully forge a packet; see AEBounds, ROBUST, and GCM-MU.  Future analyses and specifications MAY relax confidentiality or integrity limits for an AEAD.

Reviewer comments:
The analysis describes conditions where higher limits might be allowed, and provides a formula in each case that can be used to determine other limits more readily. The number of changes I've made here are somewhat frightening. This is why I resisted doing this. This will need careful double-checking. I think that this is better, but I'm not sure that I feel happy about having spent the time. The actual numbers don't concern me much, anyone can subtract 2, but the changes to the structure really need to be looked at. Some of the changes are editorial, but they still need extra eyes.
cc NAME
This issue is in response to NAME 's URL . PR introduces anti-forgery limits for packet lengths up to 2^14 as those were inherited from the maximum TLS record size. Since NAME mentioned a way to compute limits for those sizes, we should use that and put the limit in the document, instead of leaving that as an exercise to the reader.
In case it helps: https://chris-URL
Anyone care to prepare a PR for this one?
Without a PR, this will stay as is...
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.
So I talked this over with NAME and we both agree that this is not unsafe enough to block publication based on: 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. NAME 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.
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.
Hi NAME NAME NAME did I miss a recent change to our process? Since when are we closing non-editorial issues without a call for consensus?
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. NAME 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.
The flow chart is . Closing an issue that's marked neither editorial nor design isn't a scenario that's allowed according to that diagram.
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." Note that this would actually make the spec slightly shorter because you could remove the Note about how this applies to 2^14 not 2^16.
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...
We could solve this by slightly tweaking the definition of the transport parameter. OLD TEXT: NEW TEXT: If/when someone ever figures out anti-forgery limits for packet sizes above 16384, they can define an extension that negotiates that feature.
I had forgotten about this parameter. I don't think we even need an extension. We say: Then if we figure out new anti-forgery limits we remove these MUSTs. Only new implementations will send maxudppayloadsize > 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 receive limits will offer maxudppayloadsize > 16384 and older implementations can just reject longer packets out of hand which means that they don't contribute to the forgery limit.
That sounds good to me.
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.
Reducing the max packet size in QUIC v1 is fine by me, given I don't expect to exceed 16384 bytes.
NAME 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"?
Done. I hope we can resolve this quickly.
Thanks. I hope so as well. Would you like me to send a PR or should I wait for IETF LC to start?
Let's wait for some more comments on the issue. The editors were swamped.
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.
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.
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
Labeling this as "design" based on
I am moving this back to "Consensus Emerging" so we don't forget to call it out during the IETF LC.
Thanks, NAME I checked the derivations and produced the same results. This PR is exactly what I was hoping for, thanks for writing it. As far as I can tell, it's correct. It also fully addresses my concerns from .A few minor points.

Revised text:
reaching a state where key updates are not possible. For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit  <ins> is 2^23 encrypted packets; see gcm-bounds.  For </ins> AEAD_CHACHA20_POLY1305, the confidentiality limit is greater than the number of possible packets (2^62) and so can be disregarded.  For  <ins> AEAD_AES_128_CCM, the confidentiality limit is 2^21.5 encrypted </ins> packets; see ccm-bounds.  Applying a limit reduces the probability that an attacker can distinguish the AEAD in use from a random permutation; see AEBounds, ROBUST, and GCM-MU. AEAD_LIMIT_REACHED and not process any more packets. For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the integrity limit is  <ins> 2^52 invalid packets; see gcm-bounds.  For AEAD_CHACHA20_POLY1305, </ins> the integrity limit is 2^36 invalid packets; see AEBounds.  For  <ins> AEAD_AES_128_CCM, the integrity limit is 2^21.5 invalid packets; see </ins> ccm-bounds.  Applying this limit reduces the probability that an attacker can successfully forge a packet; see AEBounds, ROBUST, and GCM-MU. <ins> Endpoints that limit the size of packets MAY use higher confidentiality and integrity limits; see aead-analysis for details. </ins> Future analyses and specifications MAY relax confidentiality or integrity limits for an AEAD.