DTLS 1.3 Epoch handling

[gloinul]

Currently DTLS 1.3 key update procedure relies on a form of draining which is limiting and can impact the upper layer protocol application as they can't send new user messages during key update procedures.. Thus a better solution should be found.

[tuexen]

Hmm. A hack: When changing the epoch, change also the Shared Key ID, but use it (for now) with the same shared key. That way we should get DTLS 1.3 on par with DTLS 1.2 considering the drain game. Then we only have to solve #60...

[gloinul]

We discussed this on today's meeting and our proposal for going forward are the following:

1. We want to re-run the TLS expoerter with an DTLS epoch related input to generate a new key. Preferably this should be a defined procedure in DTLS 1.3. And it makes sense if one have relatively long lived streams and rekey a lot, as the consuming function may need to derive new keys also due the limit in key-length. If not possible to do in DTLS 1.3 spec, we will define the procedure in the DTLS over SCTP spec. This gives us SCTP-AUTH key updates in synch with the DTLS key-updates.

2. Use the same method for not having more than one older key present as for DTLS 1.2 also for 1.3.

[emanjon]

Hmm. A hack: When changing the epoch, change also the Shared Key ID, but use it (for now) with the same shared key

Does just changing the SCTP-AUTH keyID but using the same key lead to any security problems? I don't know the details of SCTP-AUTH. If the Shared Key ID is integrity protected, I think we are fine. If it is not an attacker can change the Shared Key ID which would likely lead to attacks on availability.

Probably good to derive new keys anyway using the context.

[tuexen]

The keyid is just used to let the receiver know which key to use for processing. So I see no issue right now...

[emanjon]

I made a new DTLS 1.3 issue regarding the lack of exporter rekeying

tlswg/dtls13-spec#253

[emanjon]

Is there another issue needed for the following text in DTLS 1.3?

"Implementations
SHOULD discard records from earlier epochs, but MAY choose to retain
keying material from previous epochs for up to the default MSL
specified for TCP [RFC0793] to allow for packet reordering."

My understanding is that RFC6083bis must and will violate this. If that is the case it would be good to soften the text in the DTLS 1.3 draft a bit.

[tuexen]

I agree.

[gloinul]

This issue should not any longer be relevant with the changes in #70.