IETF Logo Mail Archive

Re: [tsvwg] Errata for SCTP over DTLS

Maksim Proshin <maksim.proshin@mera.com> Tue, 21 April 2020 12:42 UTC

Return-Path: <maksim.proshin@mera.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5EC3A0AF0 for <tsvwg@ietfa.amsl.com>; Tue, 21 Apr 2020 05:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsTZ9gOWQnyR for <tsvwg@ietfa.amsl.com>; Tue, 21 Apr 2020 05:42:27 -0700 (PDT)
Received: from mail.mera.com (mail.mera.com [188.40.162.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B8D73A0AF3 for <tsvwg@ietf.org>; Tue, 21 Apr 2020 05:42:26 -0700 (PDT)
Received: from mera-exch3.mera.com ([188.130.168.213] helo=mera-exch.mera.com) by mail.mera.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (envelope-from <maksim.proshin@mera.com>) id 1jQsEK-00056V-EH; Tue, 21 Apr 2020 12:42:24 +0000
Received: from mera-exch3.mera.com (2001:67c:2344:100::23) by mera-exch3.mera.com (2001:67c:2344:100::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1591.10; Tue, 21 Apr 2020 15:42:23 +0300
Received: from mera-exch3.mera.com ([fe80::4c3d:5b6e:2eff:86ff]) by mera-exch3.mera.com ([fe80::4c3d:5b6e:2eff:86ff%6]) with mapi id 15.01.1591.017; Tue, 21 Apr 2020 15:42:23 +0300
From: Maksim Proshin <maksim.proshin@mera.com>
To: Michael Tuexen <michael.tuexen@lurchi.franken.de>, Martin Duke <martin.h.duke@gmail.com>
CC: tsvwg <tsvwg@ietf.org>
Thread-Topic: [tsvwg] Errata for SCTP over DTLS
Thread-Index: AQHWFy23vut8hAL6ZEC+lxsC7hMsTaiCFX0AgAFo1YA=
Date: Tue, 21 Apr 2020 12:41:56 +0000
Deferred-Delivery: Tue, 21 Apr 2020 12:40:50 +0000
Message-ID: <162e0727ba5a4bcea01d1930016d7d71@mera.com>
References: <CAM4esxSYQEE8QWFB72adcAhU5ZRm8J8GSvBu92Y39hacjJw9Og@mail.gmail.com> <8ED921F2-4856-4A08-A533-65361F713D39@lurchi.franken.de>
In-Reply-To: <8ED921F2-4856-4A08-A533-65361F713D39@lurchi.franken.de>
Accept-Language: en-GB, ru-RU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [5.166.200.195]
x-inside-org: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/sdF_mHgZamgCOIpS8iS8HDp0tIg>
Subject: Re: [tsvwg] Errata for SCTP over DTLS
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Apr 2020 12:42:31 -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 <tsvwg-bounces@ietf.org> On Behalf Of Michael Tuexen
Sent: Monday, April 20, 2020 8:43 PM
To: Martin Duke <martin.h.duke@gmail.com>
Cc: tsvwg <tsvwg@ietf.org>
Subject: Re: [tsvwg] Errata for SCTP over DTLS

> On 20. Apr 2020, at 18:06, Martin Duke <martin.h.duke@gmail.com> 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

v2.23.0 | Report a Bug | By Email