Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Addressing erratum #1357

Closed
wants to merge 6 commits into from
Closed

Addressing erratum #1357

Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
e84e36c
Address erratum 6151
BenSmyth May 17, 2024
57c51b3
Address erratum 6152
BenSmyth May 17, 2024
697a3b0
Address erratum 7003
BenSmyth May 17, 2024
0afea02
Address erratum 7073
BenSmyth May 17, 2024
d2a36a8
Address erratum 7620
BenSmyth May 17, 2024
909f05c
Editorial
BenSmyth May 17, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions draft-ietf-tls-rfc8446bis.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4083,8 +4083,10 @@ 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
SHOULD NOT have any effect on the read side of the sender's connection;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was discussed on the list with no clear resolution. I don't think the normative text Ben proposes is correct here, as it does not properly distinguish between the application and what it knows and the TLS stack (for instance, there might be an application-level "no-more-data" signal). Here is the text change I proposed in the thread:

"Application protocols MAY choose to flush their send buffers and immediately send a close_notify upon receiving a close_notify, but this allows an attacker to influence the data that the peer receives by delaying the close_notify or by delaying the transport level delivery of the application's packets. These issues can be addressed at the application layer, for instance by ignoring packets received after transmitting the close_notify" .

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer @ekr's language here. I'm not a fan of "SHOULD NOT have any effect" as a normative statement.

With that preference, I would prefer to have it clearer what the expectations are about responsibility for handling this situation. A TLS stack could choose to response to close_notify with close_notify, but if that has application-layer consequences, it shouldn't do that unless the application has asked it to.

I think that's what @ekr is saying, but it's a little less direct.

parties SHOULD receive a "close_notify" alert before closing the read
side of their connection. Note that this is
a change from versions of TLS prior to TLS 1.3 in which receivers 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
Expand Down