Draft: draft-ietf-quic-tls

Commentary: 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 do n'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 
 This issue is in response to 's . PR introduces anti - forgery limits for packet lengths up to 2 ^ 14 as those were inherited from the maximum TLS record size . Since 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- 
 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 do n't have anyone willing to the analysis for 2 ^ 16 ( I do n'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 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 do n't want to put this in a spec without multiple rounds of checking . points out that a change in targets also changes some MUST - level requirements and so would n'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 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 can not be closed without a call for consensus and this was never marked as a design issue . created a flowchart at some point , but I 'm failing to find it . Given the difficulty of deploying even 4k packets , I do n'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 is n't a scenario that 's allowed according to that diagram . 
 I agree with  that this does n'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  '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 . 
  .. 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 do n'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 , they can define an extension that negotiates that feature . 
 I had forgotten about this parameter . I do n'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 and only if both implementations are new will they send packets . That means that ( 1 ) sending implementations will enforce the right AEAD limits ( 2 ) only implementations which know about the new receive limits will offer maxudppayload_size and older implementations can just reject longer packets out of hand which means that they do n'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  packet size in QUIC v1 is fine by me , given I do n't expect to exceed bytes . 
 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 do n't , I 'm not understanding what a middle - ground looks like here . 
 I think I am with  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 do n't forget to call it out during the IETF LC . 
 Thanks , 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 .
Paragraph (version A):
For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit
is 2^25 encrypted packets; see gcm-bounds.  For
AEAD_CHACHA20_POLY1305, the confidentiality limit is greater than the
number of possible packets (2^62) and so can be disregarded.  For
AEAD_AES_128_CCM, the confidentiality limit is 2^23.5 encrypted
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.
Paragraph (version B):
For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit
is 2^23 encrypted packets; see gcm-bounds.  For
AEAD_CHACHA20_POLY1305, the confidentiality limit is greater than the
number of possible packets (2^62) and so can be disregarded.  For
AEAD_AES_128_CCM, the confidentiality limit is 2^21.5 encrypted
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.
Paragraph (version A):
For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the integrity limit is
2^54 invalid packets; see gcm-bounds.  For AEAD_CHACHA20_POLY1305,
the integrity limit is 2^36 invalid packets; see AEBounds.  For
AEAD_AES_128_CCM, the integrity limit is 2^23.5 invalid packets; see
ccm-bounds.  Applying this limit reduces the probability that an
attacker can successfully forge a packet; see AEBounds, ROBUST, and
GCM-MU.
Paragraph (version B):
For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the integrity limit is
2^52 invalid packets; see gcm-bounds.  For AEAD_CHACHA20_POLY1305,
the integrity limit is 2^36 invalid packets; see AEBounds.  For
AEAD_AES_128_CCM, the integrity limit is 2^21.5 invalid packets; see
ccm-bounds.  Applying this limit reduces the probability that an
attacker can successfully forge a packet; see AEBounds, ROBUST, and
GCM-MU.
Paragraph (version B):
Endpoints that limit the size of packets MAY use higher
confidentiality and integrity limits; see aead-analysis for details.