Draft: draft-ietf-quic-tls

Commentary: This defines a limit on the number of packets that can fail authentication before you have to use new keys . There is a big hole here in that AES - CCM ( that is , the AEAD based on CBC - MAC ) is currently permitted , but we have no analysis to support either the confidentiality limits in TLS 1.3 or the integrity limits in this document . It is probably OK , but that is not the standard we apply here . So this might have to remain open until we get some sort of resolution on that issue . My initial opinion is to cut CCM from the draft until / unless an analysis is produced . 
 In the interest of transparency , I have one more commit here . When I did the same for DTLS , ekr observed that if you have updated , you might safely stop trying to accept packets with the old keys rather than killing the connection . That results in loss for any packets that genuinely did want to use the exhausted keys , but that is probably less disruptive than having the connection drop . Of course , you ca n't always update , so closure is still likely necessary in some cases . 
 For what it 's worth ,  ,  , and I put together a document which might help users do this themselves : 
 Could you use that to come up with 2 ^ 16 limits and put them in the doc ? I ’m really wary of letting implementors roll their own 
 Sure ! Can you please file an issue with that request ? Noting anything else you 'd like spelled out in detail would be helpful , too . 
 tl;dr We need to recommend limits on the number of failed decryptions . At one of the side discussions concentrated on the quality of the analysis of the and the applicability of that analysis to QUIC .   , along with   ,   , and   have done a little analysis , based on and the we used to set limits in TLS . There are two relevant limits in this analysis : confidentiality bound , which is usually expressed in terms of advantage an attacker gains in being able to break confidentiality of records / packets as they get more data from valid packets . For instance , in AES - GCM , the analysis shows that after seeing 2 ^ 24.5 packets ( almost 24 million ) the attacker has a 2 ^ -60 better chance than pure chance of winning the IND - CPA game . forgery bound , which is again expressed as an probably of an attacker successfully creating a forged record / packet . Thanks to the analysis done previously , we know that AES - GCM and ChaCha20+Poly1305 have a forgery chance of 2 ^ -57 after 2 ^ 60 and 2 ^ 36 forgery attempts respectively . The current text just points to TLS 1.3 , which recommends the use of key updates to protect confidentiality . But TLS has a forgery tolerance of 0 : a single failed forgery attempt causes the connection to break . QUIC ( and DTLS ) allow for multiple forgeries to be ignored , so we need to factor that in . As discussed in if we want to maintain security , we need to consider both confidentiality and integrity . For that we need two independent limits : number of packets that are successfully encrypted and decrypted . number of packets that are unsuccessfully decrypted . We have the former already . The latter is what this issue tracks . Once the limit is at risk of being exceeded , updating keys will force the attacker to start over . Based on  's recommendation I am going to suggest that we limit forgery attempts to 2 ^ 36 . I have confirmed this with a close reading of the paper and concur . There is a significant difference here between AES - GCM and ChaCha20+Poly1305 but we believe that setting a single limit is the best approach . I will create a pull request to document this approach shortly . We could split the recommendation and allow a larger limit for AES - GCM , but I do n't believe that 2 ^ 36 ( ~68 billion ) is a significant barrier . For reference , if you were able to saturate a 10Gbps link with 50 byte IP packets that contained plausible QUIC packets , and the recipient did n't treat this as DoS traffic , it would take 5 minutes . If we assume that are more likely representative of potential packet rates , then the limit goes up to 10s of hours . I would point out that that volume of unproductive traffic is probably a good reason to use something other than a key update to deal with the sender . A reminder that the underlying analysis assumes that packets are all 2 ^ 14 in size , which is the record size in TLS . This is ~10 times larger than typical MTU on the Internet and many QUIC packets might be smaller than that , so - at least for AES - GCM - recommending a 2 ^ 36 limit is more conservative than necessary . However , if we were to allow for different limits , we 'd have to address the question of packet size , as a 2 ^ 16 byte packet will be used by some deployments . For ChaCha20+Poly1305 , the only value that matters is the number of packets , so we avoid that question . Quoting from Felix 's email for reference ( with permission ): 
 Can I request that you review this analysis for correctness ? I know that you had reservations about the claims here . 
 Another ( simplier ? ) option could be to just update keys much more often . I 've done performance tests with msquic on the effect of updating the key ~once per round trip . There was no noticeable effect on performance . In fact , more often than not , the key update perf tests happen to perform slightly better ( within noise tolerance ) than without key update . I 'm not suggesting we advocate once a round trip or anything near that ; more like every 2 ^ 20 packets ( or 2 ^ 30 bytes ? ) sent or received ( including failed decryptions ) . As I understand it , this is an ultra conservative number as far as protecting from any kind of attacks , and should be free as far as any performance impact on the connection . This also has the benefit of exercising the key update scenario more often , which should hopefully improve interoperability of the feature . 
 I support a change like this , but I am not qualified to say what the thresholds should be . There certainly is n't a reason to push it to very high limits . This change would not break interoperability , so it 's a good one . Banning CCM might break interoperability for someone , but I 'm not too concerned , particularly if we can update all the browsers to not offer it . A somewhat bigger concern is the lack of key update support in a lot of implementations : I read 9 of 15 servers as supporting it . 
 ( Tentative ) good news on CCM : Kenny identified a security analysis paper and it seems relatively simple to go from that to numbers . I am not personally concerned about support for key update . 9/15 is n't 15 , but that does n't bother me . It turns out to be a little fiddly to implement , so if people decide to drop connections that hit these limits instead , the effect is n't that bad . Of course , if you want to follow  's suggestion , that works too ( I remember   seriously suggesting a cipher that updated every record , back when I first proposed this scheme for TLS ) . 
 If we 're looking for a new bound to initiate a key update , there 's precedent in the SSH RFC to rekey after every 1 GB of data transferred . See 
 I should point out that my " 9 of 15 " figure is based on the interop matrix , where the client initiates an early update and the server responds . That is a different thing than a server initiating an update when required by the spec , which fewer than 9 servers might do . 
 Based on by  , I have calculated the bounds on the number of forgeries and encryptions for CCM . The numbers are n't great , but that probably does n't matter much for the purposes to which CCM is generally put . ( I 'm using the notation from the here because that is easier to type than some of what is being used in other papers . For reference , q is the number of genuine encryptions , l is the length of each in 16 byte blocks , v is the number of forgeries , n is the key length in bits , t is the tag length in bits . )  puts the advantage an attacker has over a generic PRF at . If we assume the same numbers in the AEBounds paper for record / packet size , ( this is for consistency , most QUIC packets will be much smaller , in the order of 2 ^ 7 , but we might also go as high as 2 ^ 12 ; this being dictated by the MTU ) . For AES , . To keep the advantage an attacker has to 2 ^ -60 ( to match the analysis in TLS ) , we therefore need to keep q to below 2 ^ 24.5 . Somewhat unsurprisingly , that matches the numbers we have for AES - GCM .  puts the advantage for an attacker over a generic PRF at . As the first term is negligible even for large v ( up to 2 ^ 64 ) , we consider the second term alone and aim for a bound on the advantage of 2 ^ -57 to match the analysis for other ciphers . That leaves us with . As q is already established to be 2 ^ 24.5 , we can say that v should be limited to 2 ^ 25 ( or if you want to be precise ) . ( As a side note , for t=64 , as in AEADAES128CCM8 , the first term becomes relevant and our security bound limits the number of forgeries to 2 ^ 7 , which is probably a bit limiting in practice . That 's good justification for not enabling AEADAES128CCM_8 by default ; though different applications might use a different target bound than 2 ^ -57 . ) I 'm an not a cryptographer . These papers all read like chicken - chicken - chicken . My calculations are not infallible either . 
 The shape of the bound seems plausible but I 'll start a thread with the cryptographers to check everything 
 I reproduced  's analysis of CCM based on of the bounds by . ( Myself not being an expert in producing such bounds , I found the second - level confirmation by Rogaway to be helpful . ) I essentially agree with the numbers , except that --when following the same metric as the -- the advantage over an ideal PRP ( instead of PRF ) should be considered . This simply means losing a 1/2 factor in the bound : Confidentiality bound : yields an advantage of . I 'd hence say it 's fine to keep TLS 1.3 's recommendation on sending  . full - sized records . Integrity bound : , hence yields an advantage of ( matching the other analyses ) . Most importantly , I concur with Martin that  would need either much lower bounds or a different risk assessment : applying the same limit of would bring the advantage incurred through the bound up to . Would it still be the best approach to define the same anti - forgery limit across all cipher suites , even if this means going down to ? Of course , I 'm happy to discuss more with ! 
 Thanks for checking this I was a little concerned about the PRP / PRF split , so I 'm glad to have you correct me . I ultimately went with per - AEAD recommendations , and a lower limit for CCM . That 's mainly to establish some sort of uniformity around 2 ^ -60 and 2 ^ -57 . Even if those are basically arbitrary choices , at least they are defensible ( I think ! ) and using them uniformly establishes the right expectations about what the standard is . I 'm comfortable with specifying different limits for each AEAD in specifications . In practice , however , I expect that a far lower tolerance for forgery attempts . Assuming that these numbers work out , a review of the pull request would be greatly appreciated . If there are other relevant papers , I 'm always happy to pull those in as well . 
 I realize that I did n't respond to That advice applies to the limits that TLS specifies already ; this issue is primarily about responding to forgeries . That said , 1 G is pretty good advice . However what we 've seen from this analysis that 1 G results in a lower safety margin than TLS aims for . But it 's close enough that if the AEAD is as good as the set we have here , you are probably OK . However , this does depend a lot on the specific AEAD . I 'd be uncomfortable using so simple a guide in the general case . 
 points out an error in my calculation . I had based my calculations on direct mapping of in the CCM analysis to in our calculations . That is , was the number of blocks in the message . But the analysis by  defines this as : ! The definition of \Beta is the CCM function , so this function really reduces to 2 times the length of the message ( in blocks ) , plus 1 ( to account for the additional encryption ) . We can ignore the extra 1 as that is absorbed by the tag length . I 'm updating the numbers in the PR . The result is another halving of the number of packets . it 's pretty clear that I 'm out of my depth here , so your input would be highly valued . 
 Good catch , yes , the double passing over the message requires a factor 2 here . ( The AD a may also be up to 3 blocks if I understand the header format correctly , but I guess that 's negligible compared to the conservative 2 ^ 10 message size . ) 
 Good point about the AD . The AD - at least for QUIC - is always sent , so that fits in the same space . We do n't necessarily need to double count the tiny number of blocks , but as you say , counting that only once yields a negligible difference . If we had a large AD that was n't also transmitted , that would be different . 
 Agreed . To be precise : if I 'm not mistaken the AD is n't counted at all right now ( accounts for the  . payload blocks ) , but of course the difference is still negligible as long as the AD is small . 
 Thanks for the edits !
Paragraph (version A):
A TLS alert is turned into a QUIC connection error by converting the
one-byte alert description into a QUIC error code.  The alert
description is added to 0x100 to produce a QUIC error code from the
range reserved for CRYPTO_ERROR.  The resulting value is sent in a
QUIC CONNECTION_CLOSE frame of type 0x1c.
Paragraph (version B):
A TLS alert is converted into a QUIC connection error.  The alert
description is added to 0x100 to produce a QUIC error code from the
range reserved for CRYPTO_ERROR.  The resulting value is sent in a
QUIC CONNECTION_CLOSE frame of type 0x1c.
Paragraph (version B):
The usage limits defined in TLS 1.3 exist for protection against
attacks on confidentiality and apply to successful applications of
AEAD protection.  The integrity protections in authenticated
encryption also depend on limiting the number of attempts to forge
packets.  TLS achieves this by closing connections after any record
fails an authentication check.  In comparison, QUIC ignores any
packet that cannot be authenticated, allowing multiple forgery
attempts.
Paragraph (version B):
These limits were originally calculated using assumptions about
the limits on TLS record size.  The maximum size of a TLS record
is 2^14 bytes.  In comparison, QUIC packets can be up to 2^16
bytes.  However, it is expected that QUIC packets will generally
be smaller than TLS records.  Where packets might be larger than
2^14 bytes in length, smaller limits might be needed.
Paragraph (version B):
The extension_data field of the quic_transport_parameters extension
contains a value that is defined by the version of QUIC that is in
use.