Re: New confidentiality and integrity limits

[Martin Thomson <[e-mail]>]

On Fri, Jun 26, 2020, at 11:01, Jana Iyengar wrote:
> Thank you for all the analysis and for distilling it into the 
> recommendations above -- the more precise bounds are super helpful!
> It seems to me that the other limits are not practical limits for the 
> most part. 

Assuming that you mean "the limits are unlikely to be a problem in practice"?  I think that is right.

The numbers that change here are forgery limits, and we expect that a real connection will have very few apparent forgeries.  In testing, I see a handful during the handshake (with my RTT, I often get Initial retransmissions that arrive after the keys have been dropped), but that's only ever about 2 packets from what I've seen.  Similarly, an implementation that drops keys aggressively around a key update might see a few near each update.  

Overall, we're talking about seeing a handful of apparent forgeries in normal use, not millions (which is the lowest limit we have).  This could mean that someone using AES-CCM will run into this limit before they hit the 2^62 packet limit, but that is unlikely to be problem for the other ciphers as their limits are higher.

This is mostly a problem for people who might be subject to sustained forgery attacks, but an attacker that sends ~8 million bad packets to close a connection has earned their ability to kill that connection.  It's not exactly an economical attack.  (For contrast, the AES-128-GCM number is ~16 quadrillion.)

> Am I correct in understanding that the practical impact of 
> this boils down to "We might need to do key updates more frequently 
> than we had hoped" since the integrity limits are a bit more modest?

Unfortunately, integrity limits are not reset by a key update, so the net effect is that you have to make a new connection.  But see above.

The confidentiality limits are marginally higher as a result of the new analysis, so you end up having to update a tiny bit less.