DTLS 1.3 Post-Handshake rekeying and reauthentication.

[emanjon]

This is not necessarily an issue for RFC6083bis, but it is likely good to have a discussion regarding the topic sooner rather than later. Deployment of DTLS 1.3 (still a draft) is several years behind TLS 1.3 but in the not-so-distant future, DTLS 1.2 should be phased out.

DTLS 1.3 is not suitable for semi-permanent connections required to be up and running for years. DTLS 1.3 removes the DTLS 1.2 renegotiation and does not replace the functionality. DTLS/SCTP relies heavily on DTLS 1.2 renegotiation. I think this needs to be fixed in DTLS 1.3 before DTLS 1.3 is suitable for semi-permanent connections. The TLS working group does likely not want renegotiation in DTLS 1.3. I see two ways forward.

1. A slimmed down post-Handshake "authentication and key exchange" that performs a Diffie-Hellman key exchange, updates the exporter_secret, and performs client and server authentication without renegotiation of any parameters (except the ephemeral keys and potentially new certs with the same identities).

2. Doing resumption in parallel with the existing connection together with post-handshake client authentication and post-handshake server authentication. Resumption performs a Diffie-Hellman key exchange and updates the exporter_secret. Post-handshake server authentication would have to be specified. With DTLS connectionID several connections can be sent over the same 5-tuple at the cost of 1 extra byte (note that the DTLS 1.3 record layer is significantly smaller than the DTLS 1.2 record layer). While resumption was not designed to be used in parallel with the original connection, I don’t think it is forbidden anywhere.

[tuexen]

Looking at DTLS 1.3 as specified right now: Which messages must be received at the client side and the server side, after which we can compute the exporter_secret at earliest time?

[emanjon]

A new exporter_secret can only be computed after resumption. You need to send the following to set up a new connection

          ClientHello
          + key_share*
          + pre_shared_key          -------->
                                                          ServerHello
                                                     + pre_shared_key
                                                         + key_share*
                                                {EncryptedExtensions}
                                                           {Finished}
                                    <--------     [Application Data*]
          {Finished}                -------->

This cannot be done over the old connection but could maybe be done in parallel with the old connection.

[tuexen]

What about the initial handshake?When can the exporter_secret be computed? I would like to understand when the AUTH keys can be deployed to avoid the receiver dropping packets because it does not know the AUTH keys yet...

[emanjon]

I am starting to think that for DTLS 1.3 we should already from the beginning specify that rekeying is done by setting up a new DTLS 1.3 connection in paralell with the old one. The new connection can use resumption or be a full handshake. By using DTLS Connection ID there can be any number of DTLS connections on a single 5-tuple. Connection ID adds one byte to the record header but DTLS 1.3 record layer is significantly smaller than DTLS 1.2. In DTLS 1.3 the record overhead is 19-24 bytes compared to 37 bytes in DTLS 1.2. So even with 1 byte Connection ID, the DTLS record layers are significantly smaller than DTLS 1.2. KeyUpdate could be forbidden.

Given that DTLS/SCTP has to keep track of the DTLS epochs, I don't see that changing epochs to connections would complicate things much (at least not if we simply forbid KeyUpdate), but maybe I miss something.

Doing the above would solve a lot (all?) of the problems with DTLS/SCTP 1.3:

• No Diffie-Hellman rekeying
• No post-handshake server authentication
• No rekeying of the exporter_secret
• 2^40.5 packets limit
• 2 minute MSL requirement

This might be the final suggestion from the TLS WG anyway. I am not sure they would like to standardize a "renegotiation"-light as that might invalidate the security proofs of TLS 1.3.

[emanjon]

One way forward could be to remove DTLS 1.3 from the document and specify that in a later document which would allow time to discuss with the TLS WG. 3GPP will likely start with using DTLS 1.2 as DTLS 1.3 is not an RFC yet and not supported by libraries.

I am not happy with the currect specification which specifies a quite bad and lacking solution for DTLS 1.3. I think that (D)TLS 1.3 or DTLS/SCTP 1.3 has to be modified. Unless modifying DTLS/SCTP 1.3 to use connection instead of epoch cause any major problems, that seems like an easier way forward.

[tuexen]

I am starting to think that for DTLS 1.3 we should already from the beginning specify that rekeying is done by setting up a new DTLS 1.3 connection in paralell with the old one. The new connection can use resumption or be a full handshake. By using DTLS Connection ID there can be any number of DTLS connections on a single 5-tuple. Connection ID adds one byte to the record header but DTLS 1.3 record layer is significantly smaller than DTLS 1.2. In DTLS 1.3 the record overhead is 19-24 bytes compared to 37 bytes in DTLS 1.2. So even with 1 byte Connection ID, the DTLS record layers are significantly smaller than DTLS 1.2. KeyUpdate could be forbidden.

Given that DTLS/SCTP has to keep track of the DTLS epochs, I don't see that changing epochs to connections would complicate things much (at least not if we simply forbid KeyUpdate), but maybe I miss something.

Doing the above would solve a lot (all?) of the problems with DTLS/SCTP 1.3:

• No Diffie-Hellman rekeying
• No post-handshake server authentication
• No rekeying of the exporter_secret
• 2^40.5 packets limit
• 2 minute MSL requirement

This might be the final suggestion from the TLS WG anyway. I am not sure they would like to standardize a "renegotiation"-light as that might invalidate the security proofs of TLS 1.3.

I read this as: We keep DTLS/SCTP simple, but enforcing limitations and require the application to deal with it by managing multiple DTLS connections. Wether they map them on the same SCTP association or not is up to the application and, in particular, the DTLS implementation used. Especially, enforcing sequencing constraints between the different DTLS connections would be left to the application.

From a point of standardising DTLS/SCTP this is fine, since it is the simplest possible way. As an implementer of an application my view would be different...

[tuexen]

One way forward could be to remove DTLS 1.3 from the document and specify that in a later document which would allow time to discuss with the TLS WG. 3GPP will likely start with using DTLS 1.2 as DTLS 1.3 is not an RFC yet and not supported by libraries.

That is definitely a way forward. However, I don't know how happy TSVWG and in particular the IESG would be to deal with two RFCs instead of one.

I am not happy with the currect specification which specifies a quite bad and lacking solution for DTLS 1.3. I think that (D)TLS 1.3 or DTLS/SCTP 1.3 has to be modified. Unless modifying DTLS/SCTP 1.3 to use connection instead of epoch cause any major problems, that seems like an easier way forward.

In my view we can only specify how DTLS 1.3 (whatever that is) can be used over SCTP. This would mean right now, how to support keyupdates.

A separate question would be whether DTLS can be used in particular use cases... This might require some work on DTLS 1.3 or just the statement, that particular use cases are not supported... Depending on the interest within the TLS WG on these use cases.

[gloinul]

@tuexen I am not interpreting @emanjon in the same way. Where we currently defining renegotiation for DTLS 1.2 to do key-updates. We would instead define a procedure that initiates a new DTLS connection over the same SCTP association. For each new DTLS connection one would export a new SCTP-AUTH key. With each DTLS record identifying the connection though an ID, we can basically do the same things as for DTLS 1.2 when it comes to handling and draining.

So all is targeting the same use cases, we just specify the additional DTLS 1.3 procedures to get a PFS solution also there and get feature compatibility.

I would suggest that we write this up in an PR so that we have something more tangible and also when doing that can see if we have missed anything.

[tuexen]

@gloinul My understanding is that we specify what happens for DTLS 1.2/SCTP, when the upper layer of DTLS triggers a re-negotiation, since re-negotiation is a feature of DTLS 1.2. For this, it doesn't matter why the upper layer is doing this.

DTLS 1.3 does support key updates and therefore we should define how that works when DTLS 1.3 is used over SCTP.

Using DTLS 1.3 in a specific way to provide additional features is conceptually different from the above in my view.

[gloinul]

It is conceptually different, but fills the same functionality, and is within the same boundaries that current DTLS/SCTP functionality has. It has a top API to ULP, it interacts with an DTLS implementation and sends and receive things over SCTP. It just that the DTLS interaction that is reshuffled.

[tuexen]

It is conceptually different, but fills the same functionality, and is within the same boundaries that current DTLS/SCTP functionality has. It has a top API to ULP, it interacts with an DTLS implementation and sends and receive things over SCTP. It just that the DTLS interaction that is reshuffled.

For an ULP perspective, there happens much more under the hood as one would expect. The ULP initiates a DTLS connection und under the hood a lot of DTLS connections are initiated.

For me this looks like a shim layer on top of DTLS 1.3, which allows you to realise a feature that DTLS does not provide (anymore). If I understand the proposal correctly, you could do the same for DTLS 1.3/UDP. So for me this is not something like How do I use DTLS 1.3 over SCTP?, but more How to I realise a particular features not provide by DTLS 1.3? and in addition to that How do I do that over SCTP?.

In my view, the scope of the document is to provide guidance on How do I use DTLS 1.[23] over SCTP?, at least this was the scope of RFC 6083.

[tuexen]

If we going to add this, we should

1. Describe in a separate section the general concept and make crystal clear that there is no relation to DTLS/SCTP. Doesn't that concept apply not only to DTLS 1.3/UDP but also to TLS 1.3/TCP?
2. Describe in text not contained in the above section, how to hide the connection management in case of DTLS 1.3/SCTP.

When implementing this feature, I expect some conceptually different problems from the ones one has to address when implementing DTLS/SCTP support, since you need to hide some stuff normally exposed via the API.

[emanjon]

Earlier comments from the TLS WG when I brought up these issues was that (D)TLS 1.3 should not reintroduce renegotiation and that long-lasting interfaces need to use several DTLS connections. I think setting up several connections is the (D)TLS 1.3 replacement for renegotiotion. KeyUpdate can be seen as a new feature required by the new AEAD limits. The more I think about it, the more I think that the current specification of DTLS/SCTP with DTLS 1.3 is not acceptable from a security perspective. I also don't think the TLS WG will not fix the issues for us unless we can show that using several connections is impossible for some reason. Let's start making a Pull Request, that should give us an idea of how well this works or not. If it works well, that is great. It something does not work we have better arguments why the TLS WG needs to do something.

[emanjon]

If I understand the proposal correctly, you could do the same for DTLS 1.3/UDP.

Yes, I this is a general problem for semi-permanent use of (D)TLS 1.3 over any layer. One option would be to have a RFC in the TLS WG that says that for semi-permanent interfaces lasting years you set up several connections. But from a TLS 1.3 perspective that would more or less be everything there is to say, expect making sure that the identities stays the same. I Waiting for such a document would likely not be worth it. The info would likely be quite obvious, and DTLS/SCTP would still have to add a lot of details of how to do key derivation for SCTP-AUTH, how to sync keys between DTLS and SCTP-AUTH, and when old keys can be deleted.

DTLS/SCTP already seems much more than use DTLS over SCTP. DTLS/SCTP specifies how to derive keys for SCTP-AUTH, how to link SCTP-AUTH keys and DTLS keys, how to deviate from the DTLS key lifetime, how identities across renegotiations needs to stay the same etc...

[tuexen]

Earlier comments from the TLS WG when I brought up these issues was that (D)TLS 1.3 should not reintroduce renegotiation and that long-lasting interfaces need to use several DTLS connections. I think setting up several connections is the (D)TLS 1.3 replacement for renegotiotion. KeyUpdate can be seen as a new feature required by the new AEAD limits. The more I think about it, the more I think that the current specification of DTLS/SCTP with DTLS 1.3 is not acceptable from a security perspective. I also don't think the TLS WG will not fix the issues for

Why is DTLS 1.3/SCTP broken from a security perspective? That would imply that TLS 1.3/TCP is also broken.

I do understand that DTLS 1.3/SCTP can not be used for a specific use case, since the DTLS 1.3 does not support it anymore and that this breakage is intentionally. But if you stay within the limits of DTLS 1.3, I don't see how DTLS 1.3/SCTP is broken. Can you elaborate on that?

I think we should describe how to use DTLS 1.3 (including key updates) over SCTP for use cases which are within the limits of DTLS 1.3.

In addition to that, we can describe how to use DTLS 1.3 for long living connections by tying together multiple DTLS connections. But let us be clear that this is a separate concept.

us unless we can show that using several connections is impossible for some reason. Let's start making a Pull Request, that should give us an idea of how well this works or not. If it works well, that is great. It something does not work we have better arguments why the TLS WG needs to do something.

[tuexen]

If I understand the proposal correctly, you could do the same for DTLS 1.3/UDP.

Yes, I this is a general problem for semi-permanent use of (D)TLS 1.3 over any layer. One option would be to have a RFC in the TLS WG that says that for semi-permanent interfaces lasting years you set up several connections. But from a TLS 1.3 perspective that would more or less be everything there is to say, expect making sure that the identities stays the same. I Waiting for such a document would likely not be worth it. The info would likely be quite obvious, and

Yes you are right. For DTLS/UDP and TLS/TCP there is not much more to say.

So I agree that only for DTLS/SCTP one has to do something to enforce the sequencing and reliability constraints.

So make that a separate section in this document, and I'm fine with this.

DTLS/SCTP would still have to add a lot of details of how to do key derivation for SCTP-AUTH, how to sync keys between DTLS and SCTP-AUTH, and when old keys can be deleted.

DTLS/SCTP already seems much more than use DTLS over SCTP. DTLS/SCTP specifies how to derive keys for SCTP-AUTH, how to link SCTP-AUTH keys and DTLS keys, how to deviate from the DTLS key lifetime, how identities across renegotiations needs to stay the same etc...

[gloinul]

The main issue here should now be resolved by #70.