Define an anti-forgery limit #3620
Conversation
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. Closes #3619.
martinthomson
added
design
Co-authored-by: ianswett <ianswett@users.noreply.github.com>
draft-ietf-quic-tls.md
Outdated
|
|
||
| Endpoints MUST count the number of packets that are received but cannot be | ||
| authenticated. Packet protection keys MUST NOT be used for removing packet | ||
| protection after authentication fails on more than a per-AEAD limit. Endpoints |
There was a problem hiding this comment.
What's a "per-AEAD limit"?
draft-ietf-quic-tls.md
Outdated
| {{AEBounds}} and {{ROBUST}}. | ||
|
|
||
| For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305 the | ||
| number of packets that fail authentication MUST NOT exceed 2^36. Note that the |
There was a problem hiding this comment.
This MUST NOT is a bit of a circuitous requirement. Perhaps "if the number of packets that fail authentication exceeds 2^36, the endpoint MUST immediately close the connection"
draft-ietf-quic-tls.md
Outdated
| analysis in {{AEBounds}} supports a higher limit for the AEAD_AES_128_GCM and | ||
| AEAD_AES_256_GCM, but this specification recommends a lower limit. For | ||
| AEAD_AES_128_CCM the number of packets that fail authentication MUST NOT exceed | ||
| 2^24.5; see {{ccm-bounds}}. |
draft-ietf-quic-tls.md
Outdated
| the use of the associated AEAD function that preserves margins for | ||
| confidentiality and integrity. That is, limits MUST be specified for the number | ||
| of packets that can be authenticated and for the number packets that can fail | ||
| authentication. Any limits SHOULD reference any analysis upon which values are |
There was a problem hiding this comment.
This is a strange SHOULD. It's a recommendation about how the spec is to be written in the future. I would remove the normative here.
draft-ietf-quic-tls.md
Outdated
|
|
||
| For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, if the | ||
| number of packets that fail authentication exceeds 2^36, the endpoint MUST | ||
| immediately close the connection. Note that the analysis in {{AEBounds}} |
There was a problem hiding this comment.
I wonder if "MUST immediately close the connection" is correct. Our recommendation, stated above, is to do a key update.
I think it would be fine to simply say "MUST NOT exceed X."
There was a problem hiding this comment.
My thinking was that this is the necessary reaction if the key update was not successful before this limit was reached. That we require a key update to be initiated before this is reached isn't any guarantee that the key update will succeed.
There was a problem hiding this comment.
I see. Thank you for the clarification.
Then, I think that the text could become less confusing if we move "MUST close the connection" to the paragraph above, and change this paragraph to just listing the numbers.
For example, the paragraph above can be changed to something like:
Endpoints MUST count the number of packets that are received but cannot be authenticated. If the number of packets that fail authentication exceeds a limit that is specific to the AEAD in use, the endpoint MUST immediately close the connection. Endpoints MUST initiate a key update before reaching this limit. Applying a limit reduces the probability that an attacker is able to successfully forge a packet; see {{AEBounds}} and {{ROBUST}}.
For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, the limit on the number of packets that fail authentication is 2^36...
Based on input from @chris-wood, it appears as though the length calculation was off. Of course, the length calculation is off anyway, because 2^10 is arbitrary and doesn't match the expected packet size. But as long as we're being arbitrary, we can at least be *consistently* arbitrary.
Co-authored-by: Felix Günther <mail@felixguenther.info>
There was a problem hiding this comment.
Thanks, @martinthomson! I derived the same bounds. This looks good to me.
draft-ietf-quic-tls.md
Outdated
| Endpoints MUST count the number of packets that are received but cannot be | ||
| authenticated. If the number of packets that fail authentication exceeds a | ||
| limit that is specific to the AEAD in use, the endpoint MUST immediately close | ||
| the connection. Endpoints MUST initiate a key update before reaching this |
There was a problem hiding this comment.
This text feels unclear to me. It could be interpreted as "you MUST close the connection and initiate key rotation" which is silly. I think what's missing is the fact that the counter of invalid packets received is reset on key rotation. But if we have a "MUST initiate rotation", what's the point of the "MUST close the connection"?
| 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 |
There was a problem hiding this comment.
This sounds scary to me. It feels like the spec is saying Computing the limits for larger packet sizes is left as an exercise to the reader. As a reader of this specification, I personally do not feel competent to get that right.
There was a problem hiding this comment.
Yes, that is what it says. And it should be scary. That is, if you want 64k packets, be prepared to read the papers. (However, if someone ignores this, the damage isn't that bad, as the worst effect from this set of AEADs is in reducing the margin by a factor of 16 to 2^-56/2^-53, which is still small.)
It also says that the margins are usually better in practice than the analysis permits.
There was a problem hiding this comment.
It would be really nice to do the math for 2^16 byte packets in this document, but I'm not volunteering so I guess I can live with this as is
| @@ -2029,6 +2079,104 @@ ffff00001b0008f067a5502a4262b574 6f6b656ea523cb5ba524695f6569f293 | |||
| a1359d8e | |||
| ~~~ | |||
|
|
|||
| # Analysis of Limits on AEAD_AES_128_CCM Usage {#ccm-bounds} | |||
There was a problem hiding this comment.
Would it make sense to move this to an appendix? Ideally I would prefer for this to not be in the draft at all, and instead have a reference to a peer-reviewed paper, but I suspect that doesn't exist today.
There was a problem hiding this comment.
This is an appendix :)
And yeah, I'm not all that happy that this is not in a peer-reviewed paper, but TLS didn't have that either. The mitigating factors are that this is being carefully reviewed (my two screwups so far have been caught), and the math is fairly simple once you get past the layers of obfuscation.
Co-authored-by: Christopher Wood <caw@heapingbits.net> Co-authored-by: Felix Günther <mail@felixguenther.info>
Only require closing the connection if you can't update. If you hit this limit, you can send a key update. You won't be able to read any packets until your peer reads that key update though. This manifests as a bunch of packet loss, because you threw out keys. So you do end up sending a bunch of packets into the dark in the hopes that one will get through. Of course, you can't always update, so you have to close then.
|
In the interest of transparency, I have added 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 can't always update, so closure is still likely necessary in some cases. |
| 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 |
There was a problem hiding this comment.
It would be really nice to do the math for 2^16 byte packets in this document, but I'm not volunteering so I guess I can live with this as is
For what it's worth, Martin, Felix, and I put together a document which might help users do this themselves: |
|
@chris-wood 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. |
Forgeries likely exhaust TWO keys
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.
Closes #3619.