Draft: draft-ietf-tls-tls13

Commentary: Currently TLS 1.3 specifies closenotify in the same way that TLS 1.2 did . I believe that has issues and this might be the right time to fix them . The purpose of closenotify is to protect against data truncation attacks , each side is required to send closenotify before closing the write side of the transport connection so the other side knows that the data was not truncated . As such , closenotify only needs half - close semantics to prevent truncation . However , the specification contains the following text : < < Each party MUST send a “ closenotify ” alert before closing the write side of the connection , unless some other fatal alert has been transmitted . The other party MUST respond with a “ closenotify ” alert of its own and close down the connection immediately , discarding any pending writes . This means that an application - layer client ca n't send a query then close their write transport when they know that they 're done , because the server would terminate the TLS session before sending the reply . On top of this , when the server receives the closenotify , it may have already sent part of the reply ( or wrote it to the socket send buffer ) so the responding closenotify would in effect be inflicting a truncation attack on the client . This does n't make much difference for HTTP because clients already do n't close their write transport after sending a reply , however having the option do do this could allow innovation in new protocols that can define the semantics of when they use closenotify . An example is DNS PUSH : A proposal to solve this problem would be to give closenotify half - close semantics : we keep the requirements that a closenotify be sent before closing the transport , and that any data received after a closenotify is ignored , but we simply remove the requirement to immediately reply with a close_notify . This has the advantage that current implementations are already compliant but future ones can leverage this improvement .
Paragraph (version A):
Alert messages convey a description of the alert and a legacy field
that conveyed the severity of the message in previous versions of
TLS.  In TLS 1.3, the severity is implicit in the type of alert being
sent, and the 'level' field can safely be ignored.  The
"close_notify" alert is used to indicate orderly closure of the
connection.  Upon receiving such an alert, the TLS implementation
SHOULD indicate end-of-data to the application.
Paragraph (version B):
Alert messages convey a description of the alert and a legacy field
that conveyed the severity of the message in previous versions of
TLS.  In TLS 1.3, the severity is implicit in the type of alert being
sent, and the 'level' field can safely be ignored.  The
"close_notify" alert is used to indicate orderly closure of one
direction of the connection.  Upon receiving such an alert, the TLS
implementation SHOULD indicate end-of-data to the application.
Paragraph (version A):
This alert notifies the recipient that the sender will not send
any more messages on this connection.  Any data received after a
closure MUST be ignored.
Paragraph (version B):
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.
Paragraph (version A):
Either party MAY initiate a close by sending a "close_notify" alert.
Any data received after a closure alert 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.
Paragraph (version A):
Each party MUST send a "close_notify" alert before closing the write
side of the connection, unless some other fatal alert has been
transmitted.  The other party MUST respond with a "close_notify"
alert of its own and close down the connection immediately,
discarding any pending writes.  The initiator of the close need not
wait for the responding "close_notify" alert before closing the read
side of the connection.
Paragraph (version A):
If the application protocol using TLS provides that any data may be
carried over the underlying transport after the TLS connection is
closed, the TLS implementation MUST receive the responding
"close_notify" alert before indicating to the application layer that
the TLS connection has ended.  If the application protocol will not
transfer any additional data but will only close the underlying
transport connection, then the implementation MAY choose to close the
transport without waiting for the responding "close_notify".  No part
of this standard should be taken to dictate the manner in which a
usage profile for TLS manages its data transport, including when
connections are opened or closed.
Paragraph (version A):
Note: It is assumed that closing a connection reliably delivers
pending data before destroying the transport.
Paragraph (version B):
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.
Paragraph (version B):
Each party MUST send a "close_notify" alert before closing its write
side of the connection, unless it has already sent some other fatal
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.
Paragraph (version B):
If the application protocol using TLS provides that any data may be
carried over the underlying transport after the TLS connection is
closed, the TLS implementation MUST receive a "close_notify" alert
before indicating end-of-data to the application-layer.  No part of
this standard should be taken to dictate the manner in which a usage
profile for TLS manages its data transport, including when
connections are opened or closed.
Paragraph (version B):
Note: It is assumed that closing the write side of a connection
reliably delivers pending data before destroying the transport.