Re: [tsvwg] Errata for SCTP over DTLS

Michael Tuexen <michael.tuexen@lurchi.franken.de> Mon, 20 April 2020 17:43 UTC

Return-Path: <michael.tuexen@lurchi.franken.de>
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 AAA0D3A093E for <tsvwg@ietfa.amsl.com>; Mon, 20 Apr 2020 10:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.287
X-Spam-Level:
X-Spam-Status: No, score=0.287 tagged_above=-999 required=5 tests=[KHOP_HELO_FCRDNS=0.275, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 0Ol7oBKAo7QF for <tsvwg@ietfa.amsl.com>; Mon, 20 Apr 2020 10:43:04 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4A83A0B69 for <tsvwg@ietf.org>; Mon, 20 Apr 2020 10:42:44 -0700 (PDT)
Received: from mbp.fritz.box (ip4d16e760.dynamic.kabel-deutschland.de [77.22.231.96]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id A8EA27220F41F; Mon, 20 Apr 2020 19:42:33 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
In-Reply-To: <CAM4esxSYQEE8QWFB72adcAhU5ZRm8J8GSvBu92Y39hacjJw9Og@mail.gmail.com>
Date: Mon, 20 Apr 2020 19:42:32 +0200
Cc: tsvwg <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8ED921F2-4856-4A08-A533-65361F713D39@lurchi.franken.de>
References: <CAM4esxSYQEE8QWFB72adcAhU5ZRm8J8GSvBu92Y39hacjJw9Og@mail.gmail.com>
To: Martin Duke <martin.h.duke@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/PnD2sdBFUEBGYq-5KJtJp1ZYVz4>
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: Mon, 20 Apr 2020 17:43:10 -0000

> 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