[spec] Proposed changes

[Scot]

(I apologize for breaking the thread view by not replying directly to
the original message.)

> ...
>
> Client authors should note that the semantics of "close_notify"
> changed between TLS 1.2 and 1.3 - only in TLS 1.3 may a client safely
> send a "close_notify" after a request to convey that it will not write
> anything further and then continue to receive the response.  To avoid
> interoperability problems, clients SHOULD NOT send a "close_notify"
> before the server does under non-error conditions.  The completion of a
> request is already unambiguously indicated by the CRLF characters.

Thanks Solderpunk for proposing these updates.

Section 6.1 of RFC 8446 [1] is specified in order to avoid truncation
attacks. Since, as you noted, the server has another way to determine
that a full request has been received, I think there is no need for a
client to send a TLS close_notify.

The server is allowed to close the read side of its TCP connection at
any time:

    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.

Since the sender of a close_notify is allowed to fully close the TCP
connection without waiting for a response, I think the RFC is
implicitely giving permission to the receiver of the close_notify
not to respond in kind.

This is also what I recall seeing in HTTP and Gemini TLS 1.3 packet
flows. Immediately after sending a TLS close_notify the server would
send a TCP FIN (disconnect) packet. When the client received the TLS
close_notify, it would not reply with its own close_notify. Rather,
it would wait for the TCP FIN packet and then reply with its own TCP
FIN packet.



[1] RFC 8446

Section 6.1. Closure Alerts

    The client and the server must share knowledge that the connection is
    ending in order to avoid a truncation attack.

    close_notify:  This alert notifies the recipient that the sender will
       not send any more messages on this connection.  Any data received
       after a closure alert has been received MUST be ignored.

    ...

    Either party MAY initiate a close of its write side of the connection
    by sending a "close_notify" alert.  Any data received after a closure
    alert has been received MUST be ignored.  If a transport-level close
    is received prior to a "close_notify", the receiver cannot know that
    all the data that was sent has been received.

    Each party MUST send a "close_notify" alert before closing its write
    side of the connection, unless it has already sent some error alert.
    This does not have any effect on its read side of the connection.
    Note that this is a change from versions of TLS prior to TLS 1.3 in
    which implementations were required to react to a "close_notify" by
    discarding pending writes and sending an immediate "close_notify"
    alert of their own.  That previous requirement could cause truncation
    in the read side.  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.

    ...