search

tlswg / dtls13-spec

Repo for DTLS 1.3
32 stars 25 forks source link

AEAD integrity limits for 0-RTT data #260

Closed emanjon closed 2 years ago

emanjon commented 2 years ago

Regarding the AEAD integrity limits the DTLS 1.3 draft states: "Implementations MUST count the number of received packets that fail authentication with each key."

As currently written the requirement does apply to 0-RTT data and client_early_traffic_secret. Keeping track of the number of times a client_early_traffic_secret has failed authentication seems demanding, especially for long-lived external PSKs. Do DTLS 1.3 implementations do that?

The suggested mitigation: "Implementations SHOULD initiate a key update with update_requested before reaching this limit."

Does not work for client_early_traffic_secret.

See also https://github.com/tlswg/tls13-spec/issues/1249

ekr commented 2 years ago

@martinthomson this is a good question. Thoughts?

martinthomson commented 2 years ago

Yes, it is a good question.

The advice about failed decryptions applies across key updates, so I would say that is easy: have it apply to 0-RTT in the same way.

The advice about the number of records that are protected are per-key. They should apply here also. In most cases it seems unlikely that you would hit those limits within the limits set by the max_early_data_size field. But there might be perverse cases. It's also possible to arbitrarily extend the use of 0-RTT without exceeding max_early_data_size by abusing padding. Saying that you should stop sending 0-RTT when you hit that limit is probably the best option.

ekr commented 2 years ago

Note to self: because of the 0-RTT anti-replay stuff, we're going to mostly get different keys due to the ticket age so this is mostly like 1-RTT.

emanjon commented 2 years ago

The advice about the number of records that are protected are per-key.

My comment was about the recieving side, i.e., the number of received packets that fail authentication.

Saying that you should stop sending 0-RTT when you hit that limit is probably the best option.

That seems like a good solution for the sending side.

ekr commented 2 years ago

The sending situation seems like it's appropriate for both DTLS 1.3 and TLS 1.3, so if we need a change it's there.

In DTLS 1.3, I agree that actually keeping track is awkward, but it's what we have. So maybe this is an RFC 6919 MUST (BUT WE KNOW YOU WON'T). I could be persuaded to downgrade it to SHOULD

seanturner commented 2 years ago

If you can do a SHOULD with a what bad things can happen if you don't, then I could go with a SHOULD.

ekr commented 2 years ago

Well it's currently a MUST in RFC 8446. So unless someone feels strongly, I believe we should just close this.

seanturner commented 2 years ago

@emanjon @martinthomson PTAL. I am hoping to close this out PDQ.

martinthomson commented 2 years ago

The only thing I would do here is say something like "As key updates are not possible for early data, a sender MUST instead cease sending early data when a key update would otherwise be required; a receiver MUST track the number of early data records that fail deprotection toward the same per-connection limit that applies after the handshake is complete." I'd be happier if RFC 8446-bis took that change though.

Happy to close this.