Allow key updates for DTLS 1.3 about draft-westerlund-tsvwg-dtls-over-sctp-bis

[emanjon]

This was allowed but not described. I made a PR describing this. A problem is that KeyUpdate in DTLS 1.3 does not change the exporter master secret so we might need to add some sequence number to the exporter....

[gloinul]

So the PR #21 does the information text. But the question about exporter remains.

[emanjon]

Yes, if new keys are needed we would need to add a sequence to the label or the context of the exporter. EAP-TLS 1.3 wanted to put a type code in the context but TLS people rather wanted concatenation with the label. (just a matter principles)

Might also be the case the we don't derive any new key for SCTP-AUTH and uses the same key during the lifetime of the DTLS connection. Untruncated HMAC-256 is very strong and has 256-bit key. (need to check these details, but I think it is a 32 byte key and tag). Without PFS the only reason to rekey would be AEAD limits.

[tuexen]

This was allowed but not described. I made a PR describing this. A problem is that KeyUpdate in DTLS 1.3 does not change the exporter master secret so we might need to add some sequence number to the exporter....

Interesting. Do you know why that master secret is not changed?

[tuexen]

Might also be the case the we don't derive any new key for SCTP-AUTH and uses the same key during the lifetime of the DTLS connection. Untruncated HMAC-256 is very strong and has 256-bit key. (need to check these details, but I think it is a 32 byte key and tag). Without PFS the only reason to rekey would be AEAD limits.

OK. But why do we perform a change of key material used by DTLS layer and not perform one at SCTP layer?

[emanjon]

The TLS AEAD (e.g. AES-GCM) need to change keys quite frequently. TLS 1.3 has put very strict limits of around s^23 records (or something like that). The HMAC-SHA256 is mush stronger and could be much longer without changign keys (for this reasons).

You might still want to change both keys to limit the effect of key leakage. That would with current TLS 1.3 require terminating the TLS connection and do resumption.

[emanjon]

I don't know for certain why the key is not changed but I can speculate.

The renegotiation in earlier versions was basically a handshake inside the connection theoretically allowing renegotiation of all parameters. It has been troubled with a lot of security issues, partly because it is big and complex. It seems to be disables in most libraries by default, but I don't know how severe the remaining security problems are.

Given this, I think the TLS working group wanted something small and simple that they could prove the security of. Also web connections are typically not that long. Some use cases of the Exported like EAP-TLS use the exporter once and then closes the connection. I guess nobody required this property when TLS 1.3 was designed.

[tuexen]

I don't know for certain why the key is not changed but I can speculate.

The renegotiation in earlier versions was basically a handshake inside the connection theoretically allowing renegotiation of all parameters. It has been troubled with a lot of security issues, partly because it is big and complex. It seems to be disables in most libraries by default, but I don't know how severe the remaining security problems are.

Given this, I think the TLS working group wanted something small and simple that they could prove the security of. Also web connections are typically not that long. Some use cases of the Exported like EAP-TLS use the exporter once and then closes the connection. I guess nobody required this property when TLS 1.3 was designed.

Thank you very much for the explanation.

[tuexen]

The TLS AEAD (e.g. AES-GCM) need to change keys quite frequently. TLS 1.3 has put very strict limits of around s^23 records (or something like that). The HMAC-SHA256 is mush stronger and could be much longer without changign keys (for this reasons).

OK.

You might still want to change both keys to limit the effect of key leakage. That would with current TLS 1.3 require terminating the TLS connection and do resumption.

Sure. Thanks for the clarification.

I was just looking for symmetry between

1. DTLS 1.2 where a renegotiation is performed to refresh keys
2. DTLS 1.3 where re-keying is performed to refresh keys

and updating the SCTP level key for 1. but not for 2.

[gloinul]

So SCTP-AUTH rekeys on DTLS connection renegotiation. Which will mean never for DTLS 1.3 unless there are future extensions to enable it. While it can occurr for DTLS 1.2. If that is correctly summarized I think this issue can be closed.