More epochs per connection (uint32 or uint64) #250
Conversation
This PR addresses #249. Larger epoch (e.g. 32-bit) seems quite straightforward. - It changes the DTLSPlaintext structure which is not sent on the wire. - It changes the RecordNumber structure used in the ACK message. This should likely contain the full epoch - It changes the 64-bit "record_sequence_number". This PR suggest the 64 low order bits of the RecordNumber. I think it could also be set to 0x0000 || sequence_number. I don't think epoch is needed here as the keys are different. Note that a 32-bit epoch still limits the number of packets in a AES-GCM connection compared to what is allowed in DTLS 1.2. 2^56.6 compared to 2^64. 2^56.5 is likely enough for all use cases but epoch could also be made even larger 2^48 or 2^64.
| @@ -324,7 +324,7 @@ meaning of the fields is unchanged from previous TLS / DTLS versions. | |||
| struct { | |||
| ContentType type; | |||
| ProtocolVersion legacy_record_version; | |||
| uint16 epoch = 0 | |||
There was a problem hiding this comment.
Can we actually change the DTLSPlaintext format like this (recalling that it is used for the initial ClientHello)?
I would mostly have expected to leave DTLSPlaintext unchanged since you are only going to be using it with epoch values less than four.
There was a problem hiding this comment.
Can we actually change the DTLSPlaintext format like this (recalling that it is used for the initial ClientHello)?
@kaduk can you elaborate on the problem here? I'm not seeing the issue.
There was a problem hiding this comment.
Can't we just keep this as uint16 and just call it epoch % 2^16?
There was a problem hiding this comment.
That seems like the simplest solution here, yeah. We can just track epoch as a uint64 internally, but only take the LSB in the plaintext here.
There was a problem hiding this comment.
(@ekr reminded me offline that this is a shared structure with DTLS 1.2, so not changing it is best.)
There was a problem hiding this comment.
(@ekr reminded me offline that this is a shared structure with DTLS 1.2, so not changing it is best.)
Right, that is the problem I was thinking of.
I think epoch % 2^16 should work, especially since we don't actually use this structure with large epochs (we've moved to DTLSCiphertext by then).
|
Based on IETF 112, closing in favor of #257. |
This PR addresses #249.
Larger epoch (e.g. 32-bit) seems quite straightforward.
It changes the DTLSPlaintext structure which is not sent on the wire.
It changes the RecordNumber structure used in the ACK message. This should likely contain the full epoch
It changes the 64-bit "record_sequence_number". This PR suggest the 64 low order bits of the RecordNumber.
I think it could also be set to 0x0000 || sequence_number. I don't think epoch is needed here as the keys are
different.
Note that a 32-bit epoch still limits the number of packets in a AES-GCM connection compared to what is allowed in DTLS 1.2.
2^56.6 compared to 2^64. 2^56.5 is likely enough for all use cases but epoch could also be made even larger 2^48 or 2^64.