Re: [TLS] RFC 8449 – DTLS 1.2 considerations

Achim Kraus <achimkraus@gmx.net> Thu, 16 July 2020 07:28 UTC

Return-Path: <achimkraus@gmx.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 92F773A1028 for <tls@ietfa.amsl.com>; Thu, 16 Jul 2020 00:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 60PoqDcu5QAR for <tls@ietfa.amsl.com>; Thu, 16 Jul 2020 00:28:27 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 8CB753A1027 for <tls@ietf.org>; Thu, 16 Jul 2020 00:28:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1594884501; bh=PnSscWlEiVtvJlUolIBbEvAqKi8FjrhQRcDr+73psrY=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=T7MEAmHCwPj9BqTNHOItw6scJ60dNLtwj7Elm/XNFnCWlcc7d9rJ63f1xgZj+OmGP Ips9hM8pzIWw4mWZdORU+u4vcgewovLSwHBddusbjfDI5lAszZZ4uEg+6p5rxhJxjp QJ5gfzt4WrOjiO8PaxVIqqlOw/rZJ1qYDtPGeo+I=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.45] ([88.65.148.93]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MCsPy-1k4o1F1OW8-008v1f; Thu, 16 Jul 2020 09:28:21 +0200
To: Martin Thomson <mt@lowentropy.net>, tls@ietf.org
References: <5713df9d-b693-ab67-0875-ea8f27bd41b7@gmx.net> <a015ef93-3770-49ae-8b25-2a52fe9582ad@www.fastmail.com>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <65876716-f4b2-82c7-24b6-dd759a52dd54@gmx.net>
Date: Thu, 16 Jul 2020 09:28:19 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <a015ef93-3770-49ae-8b25-2a52fe9582ad@www.fastmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-AT-frami
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:cel6VvMkGkE8R1yydG0X1HpcqI58+hTv+x6e2FFW1NwshgaQ8tU VYlLic1P6ZjTxtVNTKobY+dGu2VQH4mFRsYOEtgH99sGir82HeSfbtfsO9idIzoSr6cj6OV cFWp71CBB9TudH82wow0YjpGw53+Ouw1rnuGcefrs+g+3i1AOOyyfWuFC80HfqNqVb+qXOC Y1oaklUorsKVRNdI1p9vw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:1CVG8mAV0Wg=:Ydw96mRc1nTbJXmlsLC1zx ZMWIqvHtaZmZgJHxRmQSaQUFMiu18MHYR3B6sFPxlXA5gR1vN704tL9B2BS7sftSGdIWwvhyH gdDZ98o9jbsVGkwXEwZgcIbTl55Ggo/QeF0T0wGZHH6ycPZP8kNUG9qsop0CXbd10RzoDx/o4 QXfSJVYtnC1On6zK/UDBOZW3X5fCTCWDQYEU/5rCCYhrMx7pQOtEqIosM+g79mZu0gt5skK/x W3aAIZPkGBHSJcklPIC0z5ADQNfdEpVbHfcQbfhGEVRrIf0eJxLVNtCQaorf2LRdyuN1ykruc O+xWAihGAwAVuDs8bfXDIh8lUexL5FtDQVy8cG9LQr0kHA1c/L69R+JIlGQ/g+d0V+LlD+iSD pP7sjSplkooWwVoa/RVEPB4Zkaxe8mVC+SPyGIJweg2dng6QRMWhGTLxWtH9lJhJHuoynb2w2 uT2W2k1mJxoYvyYprVEJF2R0AGLkzLnJz6r6aRW1dkHlnWrEJD75P9GUCrxJaeQIceb5bP5aX igSmHW/K4wdTopzSfd7CzRz27fYzzv6Wqt61ZgNWuJouTJnYNJMNmNDr0LlrpJjV6l5k7NlTf hn8RbgI6Oyv7zD0bjX+2qBMpSpiaB1AXtrZpbw2iXfP3ZbJ9tSn4DhsmXoCnIxa6/BAdoZS9N T/Syjh8bos3rmRJLU+sy0Wjj2Jh8lMZqhtiUnupqwtJEOR5rnNajC2bWVFt/Mlz0X7MlUIG6u g9MYrKyikvxsNIV6pYsZT0oN/n1LfTA36Z5bOibV3lL8QhcBh5eYA/3pNS/s7jA0hvzKZU2vk c0ZLsVjDq5zzi9w45/wsYrnSr9XswErjxUTTbwIggmfnlGWr1YAbpm0xHidlvH6ci+AWsXstP O1u5IAbklIlrdih9GsVUg9BThVO7yLzL4lzBq83eH3Wir9VHa5uKsQA+7//ivAB1dDnqM46Lm pbZHCs18oDpgj0Y4c/hEJHn0a6gaWLXREmavyrfvWrH887wWMRTzcq/8ruy+JdjJPP4O9GX/a x/9xImXQAMxy1B5WPuB2T7+V70R80+B7TvPI1QFZ/sN/lbEPw3+0o31+8jhvb3RTN0LbFKhEg LJocrpHqE8bIKrXXUADbgsIyXFi4dJuW/62QVuWm3ruLqQHi3ZQz9v4KCKvEeQIIRA0qFXU8r 0cdovo6CFgJL2o5bFot6Rj5Q+s9+5cIxUc6Vj3nJ7S4OGRjyxWRQRkv+y2luN362YpzpKa7rK UWrovaka+dxUh4+p3GEkzhAbp3kWihgYDQKcanQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/80zT2RbXQnav0TcC50nipso2HvM>
Subject: Re: [TLS] =?utf-8?q?RFC_8449_=E2=80=93_DTLS_1=2E2_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: Thu, 16 Jul 2020 07:28:29 -0000

Hello Martin,

thanks a lot for your answer!
That helps very much to overcome my UDP confusion :-).

best regards
Achim

Am 15.07.20 um 08:41 schrieb Martin Thomson:
> 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.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>