Re: [TLS] RFC 8449 – DTLS 1.2 considerations

Martin Thomson <mt@lowentropy.net> Wed, 15 July 2020 06:41 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2223A0B0E for <tls@ietfa.amsl.com>; Tue, 14 Jul 2020 23:41:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=mz898L8r; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Z5kFTaTH
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 ZUh30iKebf4b for <tls@ietfa.amsl.com>; Tue, 14 Jul 2020 23:41:31 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEDF23A0B03 for <tls@ietf.org>; Tue, 14 Jul 2020 23:41:30 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 4E8415C00E8 for <tls@ietf.org>; Wed, 15 Jul 2020 02:41:30 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 15 Jul 2020 02:41:30 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=Enc2t9aSX48mgOgNe/1l6J0m4X1g0/b x2JblkZuXdfY=; b=mz898L8rRaJy9OGp1aUaPRNH1IZ/yyfsK9pgEIxaQkgG14w 1l0W4sm23NEUhHgUa02YRcXZjc3lU5dYRRePvcB+A4W/+MyPSmtnB9BplYoNkqkx nECWIGgyuEtHUuey1fG+7dxsVhUITMO0Gg5sY+4+7sxCtiZFYksVlZwazE2p8cC7 aiLWGGcD2yEiQWQxDEWIthxae2QH7XvJ3HW95JLMX+/F2gmLCVQgluayYsH8cLw1 BdYwiqhp6HqEV/BtE8IAXmzJ+xzOpj5tBzgn7N4nM5orSvt+seNc7YH1WfptO06i 7bRp1Nfn/igreZ8kxHP2Htje2E2HrRyQds9vIbA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Enc2t9 aSX48mgOgNe/1l6J0m4X1g0/bx2JblkZuXdfY=; b=Z5kFTaTHSdzY5Pl5A3P88w FRaylLivsgUyD42tkpjmPy6XEmoPiQViptvnmidQKiMXgXZGjsybLNIWsBYJUzfr 3ifjQk3OI/SLENX0lBlEjEJRfUrh15cqZRYHqrM5xWAxkgR143e7V0zQXQetmsWX p33vm0u/oV0D550SiHfR1Lgj5OVADLFylVSF149yQShkuq+aCphM2McHEmie8ffW Ep7NvgzCqpZ5xxUBQi/sSYCLO0nqC3vayzMhpTeiLhBAmsaCz97LsshrKuc3Nh92 oX2VBvBi1HjwS4UZqzzr7swuKoCf2Ac2AaWxzpAer1bAOhOL5LknVs+BtQPtMZyA ==
X-ME-Sender: <xms:GaUOX4DvZYVw8zK_oKvQo_G9e6LeYCr50lVIJxDXblVzMM-woDWJRQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfedugdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeehfeetudduudehtdekhf dvhfetleffudejgeejffehffevkeduiefgueevkeefleenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht
X-ME-Proxy: <xmx:GaUOX6gVinPyh-JudGuiXOPrOzTroaOVvzZDYXE0gdv0xsDWE89Sbg> <xmx:GaUOX7mAgN8mbQQfC4sNrid3mim6sMkQquoy5kGatmVwXnHl-znBGQ> <xmx:GaUOX-xwzPqAtzDzhgT7Kso0YikRR2DyK5EYQS2k68pYA65ek8cMzg> <xmx:GqUOX3C-N62umW1ZR1PubhgOuHhBdUOa1iwIQEf52nSdtpME4lHGCA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id D4CFCE00C1; Wed, 15 Jul 2020 02:41:29 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-613-g8a73ad6-fm-20200709.001-g8a73ad6e
Mime-Version: 1.0
Message-Id: <a015ef93-3770-49ae-8b25-2a52fe9582ad@www.fastmail.com>
In-Reply-To: <5713df9d-b693-ab67-0875-ea8f27bd41b7@gmx.net>
References: <5713df9d-b693-ab67-0875-ea8f27bd41b7@gmx.net>
Date: Wed, 15 Jul 2020 16:41:09 +1000
From: Martin Thomson <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XEehA10L_9ffSm_RVQvbH-xfyfA>
Subject: Re: [TLS] RFC 8449 – DTLS 1.2 considerations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jul 2020 06:41:32 -0000

On Tue, Jul 14, 2020, at 22:41, Achim Kraus wrote:
> For me it seems, that an agreement about this message buffer size is
> still missing.

This is a question we dealt with in QUIC by limiting UDP datagram size rather than the record size (or packet size in QUIC terminology).

In this case, the spec doesn't really say the most helpful thing about UDP datagram size in DTLS.  Indeed, you might say that pointing to the ability to include multiple records per datagrams is an invitation to do bad things.  After all, a receiver that receives a datagram that is too large for it likely has to drop it or only process part of it.  The partial processing is possible if there are small records, but it does lead to lots of losses.

The way I would approach this is to send one record per datagram in DTLS, no matter what the spec says.  

(NSS implements this spec, but does not assume any limits, it only respects a limit set by a peer.  For DTLS it sends one record per datagram, outside of the handshake.)

Assuming that you do have a constrained implementation that can't receive large datagrams, then we probably need different signaling.  But there are workarounds.

If you start receiving large UDP datagrams, then it is possible to drop those and hope that your peer has some sort of PMTU discovery (NSS has something, but it is crude).  At that point, the size of datagrams is limited as though it were a path limitation.  That likely gets you down to the minimum MTU for the IP version you are using.  For IPv6, that's not so different from the 1400-odd that you describe, but IPv4 - and therefore some implementations - might go as low as the IPv4 minimum MTU.

(FWIW, NSS will go as low as a 228 byte MTU, which is pretty extreme.  And it takes a lot of failed retransmissions to get that low.  I wouldn't expect that small an MTU from other implementations.)

All that said, if you have a size constraint smaller than a typical UDP MTU, then you have a very constrained implementation.  Not being able to spare ~1k but expecting to do TLS is something I struggle to comprehend.