Subject: [TLS] RFC 8449 – DTLS 1.2 considerations

From: Achim Kraus <[email-masked]>
Date: Tue, 14 Jul 2020 14:41:53 +0200

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.

https://stackoverflow.com/questions/15446887/udp-read-data-from-the-queue-in-chunks

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

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 15 Jul 2020 16:41:09 +1000

> For me it seems, that an agreement about this message buffer size is

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.

---

From: Achim Kraus <[email-masked]>
Date: Thu, 16 Jul 2020 09:28:19 +0200

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:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>