Re: [tsvwg] Errata for SCTP over DTLS

[Martin Duke <[e-mail]>]

Thanks, I marked this "held for document update"

On Tue, Apr 21, 2020 at 5:42 AM Maksim Proshin <[e-mail]>
wrote:

> Hi,
>
> We also met such behavior with the Finished message and I think b) is ok,
> and yes, OpenSSL does that. However, the Finished message is usually used
> to check that both ends can successfully decode messages after keys
> exchange so it would be good to note that in such case real data will be
> used for the check.
>
> BR, Maxim
>
> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Michael Tuexen
> Sent: Monday, April 20, 2020 8:43 PM
> To: Martin Duke <[e-mail]>
> Cc: tsvwg <[e-mail]>
> Subject: Re: [tsvwg] Errata for SCTP over DTLS
>
> > On 20. Apr 2020, at 18:06, Martin Duke <[e-mail]> wrote:
> >
> > Hello tsvwg,
> >
> > I'm seeking to verify this erratum:
> https://www.rfc-editor.org/errata/eid5744 but am definitely not an expert
> on SCTP over DTLS.
> >
> > Is this is a simple oversight in the document? A flaw in the design that
> should be fixed the next time around? Or just an incorrect report?
> Hi Martin,
>
> when sending the ChangeCiperSpec message you use the old SCTP-AUTH key,
> then you make the new active and then you send the Finished message.
> The time between the two messages might be short. They can't be in one
> packet.
>
> On the receiver side of these messages, the question is whether the new
> SCTP-AUTH key is already configured by the DTLS layer, when the second
> message is processed by the SCTP stack.
>
> Part of the answer depends on the interface between the SCTP stack and the
> DTLS stack and how the SCTP stack behaves of it receives a packet with an
> AUTH chunk using an unknown key. It could buffer it, for example, that is
> not specified.
>
> If you look at SCTP kernel implementations and DTLS userland
> implementations using the socket API, what sometimes (it is a race) happens
> is that the Finished message is processed by the SCTP stack before the DTLS
> configures the new key.
> Therefore that packet is dropped by the implementation. A timer based
> retransmission will fix that, but that is a performance impact.
>
> Ways to mitigate this are:
>
> (a) the sender waits some time between sending the ChangeCipherSpec and the
>     Finished. This is more a workaround, and since you don't know how long
>     to wait pretty hacky.
> (b) allow the Finished message to be sent with the old key. That avoids the
>     problem.
>
> If I remember it correctly, the OpenSSL implementation of DTLS/SCTP does
> (b).
>
> So I think it can be approved.
>
> Best regards
> Michael
> >
> > Thanks,
> > Martin
>
>