Layering. When we review 8446, we need to consider the layering of TLS
and transport. End of transmission is largely dependent on transport.
Traditional TLS runs on top of TCP and depends on TCP, so there may be
some value if noticing whether the closure of the transfer is expected
or not. But
On Mon, Aug 28, 2023 at 04:02:18AM -0700, RFC Errata System wrote:
> Both parties need not wait to receive a "close_notify" alert before
> closing their read side of the connection, though doing so would
> introduce the possibility of truncation.
While the paragraph text is under the microscope,
So I'm not sure this is an erratum as I think it correctly describes the
situation and it's a judgement call whether we ought to have a requirement
here or whether it's a 6919 MUST (BUT WE KNOW YOU WON'T)
We are currently preparing the 8446-bis, so I think the right place to have
this discussion
Yes, we agree. I anticipate necessity to reduce the strength my wording (or
to ignore). I raise this errata only to discuss specification-compliant
implementations being vulnerable to truncation attack; it'd surely be
better to have a SHOULD or SHOULD NOT.
On Mon, 28 Aug 2023, 14:43 Eric
Hi Ben,
Before addressing the text, let's make sure we are on the same page about
the situation.
As you probably know, there are quite a few situations in which endpoints
close the connection before
receiving a close_notify, for instance, when they receive an end of data
message in the
Hi Boris,
> (1)
In my experience, DTLS packages mainly contain a single application data
records, not more. So that limitation should not cause too much pain.
> The purpose of this format is to be used in closed networks, such as
high performance computing clusters
> (2)
If your network is
The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7620
--
Type: Technical
Hello,
I work for NVIDIA on accelerating DTLS (and QUIC) encryption in hardware.
We find that the following DTLS record aspects make acceleration less
efficient:
(1) multiple encrypted records per-packet;
(2) variable length headers; and
(3) variable length padding.
To make the protocol more
