Re: [tsvwg] DTLS over SCTP: To obsolete RFC 6083 or not?

[Gorry Fairhurst <[e-mail]>]

Thanks Magnus,

I think this is really useful input to the WG, and it would be useful to 
have people's feedback via the mailing list - or at the TSVWG  meeting 
next week.

On 16/03/2022 17:37, Magnus Westerlund wrote:
>
> Hi,
>
> I thought I would prime the discussion we will have on Monday in the 
> WG session. So the main question here is how to proceed with 
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-over-sctp-bis/. 
> There are two main alternatives that I found realistic that the WG can 
> choose between.
>
>      1. Obsoleting RFC 6083 when publishing this draft as RFC
>
>      2. Publishing as an alternative RFC to RFC6083 without obsoleting
>
> The reason I don’t think other options are on the table is that they 
> would result that there are no IETF specification for DTLS over SCTP 
> that addresses 3GPP’s clearly stated need per their LS 
> (https://datatracker.ietf.org/liaison/1723/). It is also clear to me 
> having now worked on this document a bit more than a year that there 
> are a number of short comings of RFC 6083. Many of them has actually 
> been caused by RFC 8996 obsoleting DTLS over SCTP usage of prior DTLS 
> version than 1.2. Another aspect is the general aging of SCTP-AUTH and 
> lack of maintenance update of that specification to address SHA-1 
> status of being non-recommend algorithm in general, but being the 
> mandatory to implement in RFC 4895.
>
> The main issues due to these aging dependency are:
>
>   * RFC 6083 relies on DTLS to rekey the DTLS connection.
>       o For DTLS 1.2 there exist support for renegotiation with mutual
>         authentication which is good. However, there are some security
>         risks here that needs to be mitigated and a number of
>         implementations have simply disabled the functionality.
>       o DTLS 1.2 is limited to 65534 rekeyings which could potentially
>         affect really long lived associations or with high bandwidth
>         forcing rekeying.
>       o DTLS 1.3 lacks renegotiation and can only do a key-update.
>         Which has several impacts:
>           + first of all no mutual re-authentications
>           + secondly key-update does not result in any new master
>             secret which results in that SCTP-AUTH will have a single
>             key for the whole SCTP association life time. Which will
>             limit the SCTP association life-time.
>           + Third, no forward secrecy is provided
>   * SCTP-AUTH may use SHA-1 unless individual implementation ensure to
>     move it into less preferred status, but none of the current in
>     force RFCs recommend to do this.
>   * Lack of updated security considerations for the protocol with
>     either DTLS versions. Where especially DTLS 1.2 really can benefit
>     from recommendations for crypto algorithms to use etc.
>
> The other reason why an new DTLS over SCTP specification is need has 
> to do with the properties and features that the WG draft provides 
> compared to RFC 6083. To summarize the high level differences:
>
>  1. User message sizes of at least 2^64-1 bytes are supported. Some
>     senders may be more limited due to their SCTP API, but still
>     significantly more that 16384 bytes that RFC 6083 provides.
>  2. The usage of DTLS/SCTP is negotiated during the SCTP association
>     handshake with makes it clearer that DTLS/SCTP want to be used. It
>     also allow us to ensure that all user messages are protected.
>  3. The impact on the ULP’s usage of SCTP when protecting user
>     messages with DTLS has been further reduced:
>      1. We have removed the requirement to use stream 0 and that this
>         stream is configured to send in-order reliable user messages.
>      2. The rekeying mechanism also can avoid the need draining all
>         user messages from the SCTP association before changing key,
>         i.e. the ULP does not need to pause its usage until the key
>         has sent.
>  4. A rekeying mechanism that provides mutual authentication, forward
>     secrecy, SCTP-AUTH rekeying, and no practical limitation on SCTP
>     association life span. It also is substantially more independent
>     of DTLS version than RFC 6083 in its core mechanism.
>
> The document also clarifies a couple of interactions that might not 
> have been completely described in RFC 6083. For example the shutdown 
> procedure for the peer to the one initiating the shutdown.
>
> So I hope it is fairly clear that not producing a new specification 
> for DTLS over SCTP would be bad. Thus, we are back to the two 
> reasonable options I see:
>
>  1. Obsoleting RFC 6083 when publishing this draft as RFC
>
>  2. Publishing as an alternative RFC to RFC6083 without obsoleting
>
> The WG can come to consensus to leave a RFC 6083 in place for those 
> use cases that can live with the limitations stated above including 
> message size. However, it also leaves those users with some pitfalls 
> when it comes to security. I would strongly recommend if there are a 
> proponent for B, that they should actually make an update to RFC 6083 
> to address at least the security considerations for how to safely use it.
>
> I personally think the only reason for not picking A. is the IPR 
> declarations made (https://datatracker.ietf.org/ipr/5195/ and 
> https://datatracker.ietf.org/ipr/5218/). I hope any proponent for B 
> are either currently using RFC 6083 in a solution where it works for 
> them, or are planning to use it, and see the IPR as a significant hurdle.
>
> So please provide your opinion. Also don’t hesitate to ask for 
> clarification on any aspect of the above.
>
> Cheers
>
> Magnus Westerlund
>
> Co-author of draft-ietf-tsvwg-dtls-over-sctp
>
To me this seems a great summary, and possibilities could indeed include 
also a minor update to RFC603.bis to solve pitfalls.  I hope we can make 
progress on this topic over the next week.

Gorry

(TSVWG Co-Chair)