Re: [tsvwg] DTLS 1.3 over SCTP

[Magnus Westerlund <[e-mail]>]

Hi Michael

> This seems to be a generic to long living (D)TLS connections. This is not related to SCTP at all.
> Shouldn't such a text be in a BCP, preferably coming from the TLS WG? Wouldn't it make sense to
> address it in a generic way for (D)TLS?

MW: I don’t see how to address this in TLS WG without a substantial extension. I think it is equivalent to bringing back renegotiation for TLS. That would first need to be specified and then implemented. That works very poorly with the time plan we are trying to meet to deliver a solution to 3GPP. This is a problem we have had a solution in the SCTP/DTLS draft since https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-over-sctp-bis/02/ for by utilizing parallel DTLS connections. We are using the same solution in Crypto Chunk with DTLS. We have a work around that uses existing DTLS, that gives us the properties we have identified as what 3GPP need. This solution has been reviewed by Martin Thomson, and I have been promised more reviews by other prominent participants TLS WG to look at the updated version as soon as we have chosen a direction. So, I see no need to delay this work several years, which would be very negative for our cooperation with 3GPP.
>  So 3GPP has not expressed these requirements in any of the LS we have received. My understanding is that we have considered necessary requirements for the applications and their properties to meet modern security recommendations. John is on vacation, but I will see if I can learn if there exists some 3GPP documentation on requirements that I can point to, or if anyone else that can contribute their view on 3GPP.
> I hope you see that forward secrecy and the possibility to re-run (EC)DHE exchanges periodically is quite relevant to minimize the impact of any breach if it would occur for this very long lived SCTP associations that these 3GPP applications are using as well as for any other usage of this security mechanism.

> The above reads consistent and I'm not against it. I just saying that such non transport specific considerations
> might be best discussed in the, for example, TLS WG. I'm not sure if TSVWG is the right WG for it; and if
> a protocol specification is the right place. A BCP describing TLS policies seems more appropriate to me.

MW: Sorry, I think you need expand on your reasoning here. We are working on an integration of a security solution with a transport protocol. This requires combing the security mechanism with the transport protocol such that both the desired security properties and the transport protocol functionality is fulfilled. In this case 3GPP’s applications using SCTP are such that we have security requirements that exists in other works like IPsec but haven’t been in the forefront in other work such as QUIC, HTTP and DTLS.

I can understand the desire to make a minimal update to RFC 6083 work. But you have two different sets of requirements that https://datatracker.ietf.org/doc/draft-tuexen-tsvwg-rfc6083-bis/ don’t fulfill.

  1.  Support of large enough messages
  2.  Fulfil re-authentication and long lived sessions with good security properties
If you go to TLS WG and manages to get renegotiation extension for TLS you will likely have solved 2). However, issue 1) still remains. This while we have two different proposals that solve both of these sets and is what 3GPP needs. My focus for the upcoming meeting is to get a consensus decision not to long after the IETF meeting for which direction we are taking on this. I have no issue with you continuing with a proposal for updating RFC 6083 that is more limited however and potentially IPR free. However, for now can we focus on the solution that is more capable and fulfills 3GPPs requirements and make good progress on that and keeping these two separated.
When it comes https://datatracker.ietf.org/doc/draft-tuexen-tsvwg-rfc6083-bis/ I think you can consider how to get TLS WG to solve the long lived TLS connection issues. We would be supportive as this issue may arise again related to TLS but we will not consider such a direction for solving DTLS for SCTP until that work is very mature. Secondly, if you are extending the TLS record size beyond the 2^14 bytes the current limit is, then I really request that you get some analysis into what it does to the various ciphers’ properties. There are likely many that are fine with a four times expansion of the data per invocation, but maybe not all of them are. Nonce construction limits could exist, and key usage limits may be impacted by this change and therefore needing per cipher recommendations.
Regards
Magnus Westerlund