Extended epoch like tls. Fixed #249 #257
Conversation
|
This seems promising. |
There was a problem hiding this comment.
Many implementations of DTLS use a 16-bit integer to hold epoch. Sometimes, that leaks into places that mean that it is hard to change.
Those of us with this problem can probably pull the same trick as here and only expose the low 16 bits, but would it be possible to implement this without allowing key updates that take epoch to 2^16?
draft-ietf-tls-dtls13.md
Outdated
| of the connection epoch, which is an 8 octet counter incremented on every | ||
| KeyUpdate. See {{seq-and-epoch}} for details. The sequence number is set to | ||
| be the low order 48 bits of the 64 bit sequence number. Plaintext records | ||
| MUST NOT be sent with sequence numbers that would exceedd 2^48-1, so the |
There was a problem hiding this comment.
| MUST NOT be sent with sequence numbers that would exceedd 2^48-1, so the | |
| MUST NOT be sent with sequence numbers that would exceed 2^48-1, so the |
draft-ietf-tls-dtls13.md
Outdated
| @@ -2151,6 +2164,14 @@ Client Server | |||
| ~~~ | |||
| {: #dtls-key-update title="Example DTLS Key Update"} | |||
|
|
|||
| Implementations MUST NOT send KeyUpdates that would result | |||
| in epochs of greater than or equal to 2^{48}-1. This limits | |||
There was a problem hiding this comment.
This is somewhat arbitrary. If the epoch can have 64 bit values, then why not allow for the full range of values to be used? Is there an analysis that suggests that rekeying too often leads to this problem?
Also, I would have said >2^48-1 OR >= 2^48, but not this. I can almost guarantee a test failure in some compliance test arising from that choice. The test will be pointless too.
There was a problem hiding this comment.
With a key space of 2^{128}, 2^{64} rekeys has a significant chance of key repetition.
The IV randomization is intended to address this, but I prefer to be cautious, especially as there is no realistic scenario in which > 24^{48} rekeys will be needed.
There was a problem hiding this comment.
Happy to change this to >= 2^{48}
There was a problem hiding this comment.
If we accept the premise that the nonce is effectively part of the key space, then AES-128 is still probably OK with that many rekeys. AES-256 and ChaCha20Poly1305 have no such problem. I'm just concerned that this is arbitrary and unexplained.
|
@ekr this LGTM, but there's a conflict. Can you resolve prior to merging? @martinthomson, are you OK with the new rationale, and text that allows it to be relaxed in the future? |
| enforce this rule. If a sending implementation receives a KeyUpdate | ||
| with request_update set to "update_requested", it MUST NOT send | ||
| its own KeyUpdate if that would cause it to exceed these limits. |
There was a problem hiding this comment.
What can it do instead?
Co-authored-by: Martin Thomson <mt@lowentropy.net>
Yet another attempt to fix #249.
This builds on Chris's PR but just omits the epoch entirely from the AEAD nonce calculation. This is more consistent with TLS and doesn't require special case reasoning about why we only need to build in the bottom 16 bits. This relies entirely on the keys being different. Needs analysis.