Subject: [tsvwg] Errata for SCTP over DTLS

From: Martin Duke <[email-masked]>
Date: Mon, 20 Apr 2020 09:06:12 -0700

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?

Thanks,
Martin

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 20 Apr 2020 19:42:32 +0200

> On 20. Apr 2020, at 18:06, Martin Duke <[email-masked]> 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

---

From: Maksim Proshin <[email-masked]>
Date: Tue, 21 Apr 2020 12:41:56 +0000

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 <[email-masked]> On Behalf Of Michael Tuexen
Sent: Monday, April 20, 2020 8:43 PM
To: Martin Duke <[email-masked]>
Cc: tsvwg <[email-masked]>
Subject: Re: [tsvwg] Errata for SCTP over DTLS

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.

Best regards
Michael

---

From: Martin Duke <[email-masked]>
Date: Tue, 21 Apr 2020 09:23:32 -0700

Thanks, I marked this "held for document update"

On Tue, Apr 21, 2020 at 5:42 AM Maksim Proshin <[email-masked]>
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
>
> 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.
> SCTP-AUTH key is already configured by the DTLS layer, when the second
> message is processed by the SCTP stack.
>
> 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.