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 if TLS is used in QUIC, the integrity of the transfer is an
issue for QUIC itself, not for the TLS component. Which begs the
question: what part of TLS is "core", and what is an adaptation to TLS
over TCP? Should that be split, in some kind of layered specification?
Speaking of QUIC, there were quite a bit of debate about the proper way
to signal the end of connections. One of the results was support for
"silent closure when the endpoints remain silent for the idle timeout",
because requiring additional messaging would create extra load for the
servers and consume extra power on the clients.
Back to layering. "I am done and I have sent or received everything I
meant to send or receive" is primarily an application concept. Different
applications have different notions about that. Forcing that handling
inside TLS seems wrong, even if we can conjure "truncation attacks"...
-- Christian Huitema
On 8/28/2023 7:38 AM, Viktor Dukhovni wrote:
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, its last sentence
looks particularly unclear to me. Could it get a more clear rewrite?
Perhaps:
Neither party needs to wait to receive a "close_notify" alert from
the peer before closing its read side of the connection. Note that
tolerating connection closure by the peer without a "close_notify"
can introduce opportunities for truncation attacks.
The above suggested wording change serves two purposes:
- Replaces the (to me at least) confusing "both need not" with
"neithe needsr".
- Clears up the truncation attack language. The issue, as I
understand it, is not choosing to close the read side before
"close_notify", but rather accepting EOF (peer's closure of his
write side) without a "close_notify".
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
