[TLS] RFC 8449 – DTLS 1.2 considerations

Achim Kraus <achimkraus@gmx.net> Tue, 14 July 2020 12:42 UTC

Return-Path: <achimkraus@gmx.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EDA393A0B80 for <tls@ietfa.amsl.com>; Tue, 14 Jul 2020 05:42:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id C6hTb9ZbfR4N for <tls@ietfa.amsl.com>; Tue, 14 Jul 2020 05:41:59 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net []) (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 2BB203A0BE7 for <tls@ietf.org>; Tue, 14 Jul 2020 05:41:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1594730515; bh=2+QU6iVRvylsvdsVbX279bIJrsYySBV25BLOkgBSqjA=; h=X-UI-Sender-Class:To:From:Subject:Date; b=G7XEqgsB/q/E2tRZauthAIWjyR1kLIjJeBD92h8fQnHAvJHLvvHwX2N/ECNQqwrIf oqPP5JSuPl7vKrujW1X+doud88Vf7f2aNn3PI75bpHH+U2G7ZJhyfurJG2m8DRuZQ/ k914JhWBbFVizW8ThtEFYBIZ6cmscG/I57tSJnso=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by mail.gmx.com (mrgmx005 []) with ESMTPSA (Nemesis) id 1Mr9Fs-1kh1c43Epy-00oFCG for <tls@ietf.org>; Tue, 14 Jul 2020 14:41:54 +0200
To: "tls@ietf.org" <tls@ietf.org>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <5713df9d-b693-ab67-0875-ea8f27bd41b7@gmx.net>
Date: Tue, 14 Jul 2020 14:41:53 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:IXUTkmY32NnXoY6cE0vBiC+nAh92Y1urErFumZlctIhLGhgXRSi Fa5MkVJLYLsTnTqK0OhGaNLh5Gk7ZJQtVpDR1n01++wDccGVqIRr/rvke951t/tv+Ao4yYN amRJpyui5YV1VaTkZo2nfauvZG5kUEADx2/uoDtKonIuRsRyM+eLmBdGs7/9RV6Z7MueRDa o9yT4jcQ2DcuCLg3HTuCw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:QH/nOzabz4I=:7+Z3ZgJgnvHf7l2ytdBC7i 3RvNj5mV06WGiQdE7kstULaUHioXUtL8JZfpAeXkwK9iYnUwudmTuJ8qfLSeJBzwxTNG8JhrK Vaizu778+PUUiaV2LHe04mKo+PPT9mmyM/+LP25s5u9+mo/OW4fEO0enjmhrv2Zj1haTXZrB5 +xyipd0ZeDM79QEBNYIQTXokT6Z+U7oM2li4bE8+SPVtmcvxi3IdEqIXVVrJbnb2tGGX7RN0y 1RDZ+lVgN6x54i+vWL3Y83NwB0EvtPvcfQCWHCxz67nT8Om8ylskw44w2Z+G5lpGPUTcMimYj AxBfYtAcKyn56Te9cVbRV0hGj5JWIBDvZAlMqbrwKVGhgly8rNaISPExyI9IWu1p/OWdl+m59 t5hgxf8Qnawlbk71ZmIIs58KFKHIAR6JF2knanESis6c/00IrjliJOuMXj21Vqlli/2C9J6Vv E+vzPwISWfIboZj1OcTKfG2b3H8mdp9jTrG7Qg5F2ojqGn4qrLjcQlrTsFYJ/iP2iaKFkLscA lkF4ZBjUAFIIMeqZTA36gMYH3F3V5JsaX2jK5mIEYjKA/T+CzlRXR6k1jk8+JRTYXFLzJSAyH x0DRf4Lo9WM6sbBRyUMsmO1Dve4E4E9tItGuuDaAssLyB/RGYNGkiR+pRZolA8wB1D/2i+ayo uAq13ITQGO+ZL3N3K8RQ1v0ll1LxKQoP+VEho2ShNSgM6ZotcOm2tusmFDHkDdLb2NQkhTFJ6 z6DiiwNecpjnaWn/8wXc3zhhGNCrTO1/zpyM+nBSIFaNm0KWwWtZn2m3I5vPM6nTn2DENVLET 09sdB+e38Ybwj+hWzh7H5JfAnmzSW8TFNKLy4dMhig4W5WCn6XS9HTpHlWWs7IHNNgwwwKikV qNoU6dNEOvu17PD2PT1qblYPQd8abb2MFg3q0us0Ty/yYhF4L/ffz5xUpTsNooRiqtz1Btupc DzwUTYbE5AbVLl+0bLN16bXEaV76IpOahuILaexfIF/b2G2yFpCKRCjnff9VId/YUh4zrHDNg RvTjxAPb9ED36TBgtPc7irFbveEFv+IrlkChssUqfenzXcyViLIlj1vuxQH2SqZ1xWP38wZoM VJtm628ZLjcsXso50CDsWsl0fe2t/b7SRisgnIJahYs8Y60vGNKLArfMDsYQaf4rePBgDTz0W v0540S+eoQqri4dwsYI3qrMaGywnYSvKgIfq188/3k7wKeRImnUIt80CEsESnVV7QGTxxcOHQ arf1JCihD9RYu8EINR7kyqLMOz5g70PRKlu8RUw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/NxSdyUk3Err0gJGOjnjCysuAT04>
Subject: [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: Tue, 14 Jul 2020 12:42:01 -0000

Hello list,

implementing a first experimental version of RFC 8449 for DTLS 1.2 in
the Eclipse Open Source Project "Californium", I got some doubts about
statements, which seems for me to be only applicable, if a API for
chunked read/write operations is available.

RFC 8449, Section 3, page 4

“Constraints on record size are often receiver constraints.
In comparison, an implementation might be able to send data
incrementally. Encryption does not have the same atomicity
requirement. Some ciphers can be encrypted and sent progressively.
Thus, an endpoint might be willing to send records larger than the
limit it advertises for records that it receives.”

That matches pretty well the TCP APIs, which supports a chunked usage
(by the cost of resources in the TCP stack itself). I’m not sure, how
this could be applied to UDP. I’m not aware of a “chunked” API for UDP.
A web search also didn’t fill that gap, others seems also to fail as well.


So, should that be applicable for UDP?
If so, would it be possible to provide some information about the API to
be used for that?

RFC 8449, Section 4, page 6

“PMTU governs the size of UDP datagrams, which limits the size of
records, but does not prevent records from being smaller. An
endpoint that sends small records is still able to send multiple
records in a single UDP datagram.”

I would agree, if UDP offers a “chunked API”. Without, all records must
be assembled before passing them to the UDP stack. That would end up in
supporting a “negotiated, limited crypto buffer” and a “not-negotiated,
larger message buffer”.

For me it seems, that an agreement about this message buffer size is
still missing.
That may be a simple agreement for minimum message buffer size (e.g.
1472 bytes), or a estimated  size from this record size limit (but that
would cause a conflict with the page 6 and additionally with, RFC 8449,
Section 4, page 4, “Unprotected messages are not subject to this limit.”).

So, how do other DTLS implementations deal with that message buffer size?

Best regards
Achim Kraus