Expand AEAD limits to consider multi-user security. #3789
Conversation
In a typical multi-user setting, the adversary is assumed to perform some (massive) amount of offline work to break the integrity of a single random connection. Each user is represented as a unique (key, nonce) pair. In considering the same threat model, we must treat each key resulting from a KeyUpdate event as a unique user. As a result, roughly speaking, bounds implied from the multi-user setting imply (minimally) for the lifetime of a single connection. Hoang et al. [1] present tight multi-user security bounds for randomized AES-GCM (as is used in TLS 1.3 and QUIC), so we can take advantage of those for per-connection integrity limits. (Confidentiality limits still apply per-key, as the analysis considers only encrypted blocks, which would not change if an endpoint updated its key or created a new connection.) In contrast, there are no multi-user security bounds for AEAD_CHACHA20_POLY1305 or AEAD_AES_128_CCM, so we must use the single-user bounds in their stead. [1] https://dl.acm.org/doi/10.1145/3243734.3243816
| The analyses that follow rely on a count of the number of block operations | ||
| involved in producing each message. For simplicity, and to match the analysis of | ||
| other AEAD functions in {{AEBounds}}, this analysis assumes a packet length of | ||
| 2^10 blocks; that is, a packet size limit of 2^14 bytes. |
There was a problem hiding this comment.
I don't understand how this impacts the analysis, but why is packet size 2^14 bytes? For QUIC, I would suggest that 2^11 ought to be adequate (if a larger packet size is more conservative).
There was a problem hiding this comment.
We decided that matching the TLS analysis in this regard is best. Using the larger number is more conservative, so the margins in practice will be better than what we have calculated here.
There is of course the theoretical limit on QUIC packets, which is 2^16 bytes or 2^12 blocks, but as you say, they are mostly much smaller. There is an existing note about this discrepancy for those running a massive MTU.
There was a problem hiding this comment.
Where's the note? Perhaps a pointer to that here would be helpful. Should the integrity/confidentiality limits be made explicit for 2^16-byte packets?
There was a problem hiding this comment.
Line 1588 (on the new side). David raised an issue requesting that we provide limits based on an assumption of 2^16 byte packets. If we do that, we might want to do a split between 2^11 and 2^16 rather than having 2^14. We should track that on that issue though.
There was a problem hiding this comment.
Agreed. I'd prefer if we left the 2^16 limits to a separate issue.
There was a problem hiding this comment.
When people say 2^11, do they think 1536 bytes? This is indeed a common packet size. The next interesting size are probably in the "jumbo frame" range -- see for example 9001 bytes mentioned for AWS. That would be 2^14. And then the UDP limit is indeed 2^16.
Co-authored-by: Jana Iyengar <jri.ietf@gmail.com>
Co-authored-by: Jana Iyengar <jri.ietf@gmail.com>
Co-authored-by: Jana Iyengar <jri.ietf@gmail.com>
Also, split out the integrity limit text again for parallel flow.
| this limit. If a key update is not possible, the endpoint MUST immediately | ||
| close the connection. Applying a limit reduces the probability that an attacker | ||
| is able to successfully forge a packet; see {{AEBounds}} and {{ROBUST}}. | ||
| Endpoints MUST count the number of encrypted packets for each set of keys. If |
There was a problem hiding this comment.
Can this clarify who is doing the updating? If I've sent 2^27 or received 2^27 do I initiate?
There was a problem hiding this comment.
This is an existing ambiguity. And the answer is that either endpoint can do the update. As updates are symmetric, this isn't a big deal, but you can stumble over each other if you do it poorly.
I haven't implemented this bit yet, but when I did it for TLS, the sender updates at limit-N and the receiver requests an update at limit-M where M < N. This is because the primary responsibility for the update lies with the sender. This stops endpoints using the same implementation from doing near-simultaneous updates, which is a little wasteful. If M for one implementation matches N for another, then you can still get a race. Of course, QUIC handles simultaneous updates well, so maybe you don't care for that level of sophistication.
There was a problem hiding this comment.
I'll second that. IKEv2 simultaneous key update is so complicated that most configurations I've seen intentionally use different limits on both endpoints to reduce the odds of a simultaneous rekey. In QUIC however, simultaneous rekey has the same complexity as regular rekey so I don't think it's worth working around.
martinthomson
added
-tls
design
This corrects an arithmetic error in the calculation of the confidentiality limit for AES-GCM. It also changes to using a fixed advantage target of 2^-57 for both confidentiality and integrity. The inconsistent use of different limits was making it hard to reason about. As the overall target is AE security, the net effect of this is a factor of 2 improvement in attacker advantage over what is in the TLS analysis, which was 2^-57+2^-60. This moves to 2^-56 overall, which is cleaner. In doing so, I discovered that the integrity limits for both AES-GCM and AES-CCM were being set independent of the confidentiality limits, but that the confidentiality limits assumed limits on the number of forgeries. As a result, the limits on forgeries had to be capped based on those assumptions.
More on AEAD limits
|
(Thanks, @martinthomson!) |
draft-ietf-quic-tls.md
Outdated
| 2^36 forged packets; see {{AEBounds}}. For AEAD_AES_128_CCM, the integrity limit | ||
| is 2^23.5 forged packets; see {{ccm-bounds}}. Applying this limit reduces the | ||
| probability that an attacker can successfully forge a packet; see {{AEBounds}}, | ||
| {{ROBUST}}, and {{?GCM-MU}}. |
There was a problem hiding this comment.
Nit: I wouldn't use "forged" here but rather "invalid". We don't know why they are invalid.
| this limit. If a key update is not possible, the endpoint MUST immediately | ||
| close the connection. Applying a limit reduces the probability that an attacker | ||
| is able to successfully forge a packet; see {{AEBounds}} and {{ROBUST}}. | ||
| Endpoints MUST count the number of encrypted packets for each set of keys. If |
There was a problem hiding this comment.
I'll second that. IKEv2 simultaneous key update is so complicated that most configurations I've seen intentionally use different limits on both endpoints to reduce the odds of a simultaneous rekey. In QUIC however, simultaneous rekey has the same complexity as regular rekey so I don't think it's worth working around.
Closes #3788.
In a typical multi-user setting, the adversary is assumed to perform some
(massive) amount of offline work to break the integrity of a single random
connection. Each user is represented as a unique (key, nonce) pair. In
considering the same threat model, we must treat each key resulting from
a KeyUpdate event as a unique user. As a result, roughly speaking, bounds
implied from the multi-user setting imply (minimally) for the lifetime of
a single connection.
Hoang et al. [1] present tight multi-user security bounds for randomized AES-GCM
(as is used in TLS 1.3 and QUIC), so we can take advantage of those for
per-connection integrity limits. (Confidentiality limits still apply per-key, as
the analysis considers only encrypted blocks, which would not change if an endpoint
updated its key or created a new connection.) In contrast, there are no multi-user
security bounds for AEAD_CHACHA20_POLY1305 or AEAD_AES_128_CCM, so we must use the
single-user bounds in their stead.
[1] https://dl.acm.org/doi/10.1145/3243734.3243816