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 all commits
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
25 changes: 14 additions & 11 deletions draft-ietf-tls-rfc8446bis.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -444,7 +444,7 @@ properties.
TLS consists of two primary components:

* A handshake protocol ({{handshake-protocol}}) that authenticates the communicating parties,
negotiates cryptographic modes and parameters, and establishes
negotiates cryptographic algorithms and parameters, and establishes
shared keying material. The handshake protocol is designed to
resist tampering; an active attacker should not be able to force
the peers to negotiate different parameters than they would
Expand Down Expand Up @@ -705,7 +705,7 @@ in the diagram above):
In the Key Exchange phase, the client sends the ClientHello
({{client-hello}}) message, which contains a random nonce
(ClientHello.random); its offered protocol versions; a list of
symmetric cipher/HKDF hash pairs; either a list of Diffie-Hellman key shares (in the
symmetric cipher/Hash pairs; either a list of Diffie-Hellman key shares (in the
"key_share" ({{key-share}}) extension), a list of pre-shared key labels (in the
"pre_shared_key" ({{pre-shared-key-extension}}) extension), or both; and
potentially additional extensions. Additional fields and/or messages
Expand Down Expand Up @@ -1560,7 +1560,7 @@ Random set to the special value of the SHA-256 of
C2 A2 11 16 7A BB 8C 5E 07 9E 09 E2 C8 A8 33 9C

Upon receiving a message with type server_hello, implementations
MUST first examine the Random value and, if it matches
MUST examine the Random value and, if it matches
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't believe this, and by extension Erratum 6152, is correct. The order of operations is:

  1. Look at SH.Random to determine if it's actually an HRR
  2. If it is a HRR, then follow the HRR processing steps described in 4.1.4.
  3. If it a SH, then follow the SH processing steps described in 4.2.1.

this value, process it as described in {{hello-retry-request}}).

TLS 1.3 has a downgrade protection mechanism embedded in the server's
Expand Down Expand Up @@ -2896,7 +2896,8 @@ flight. The Certificate and CertificateVerify messages are only
sent under certain circumstances, as defined below. The Finished
message is always sent as part of the Authentication Block.
These messages are encrypted under keys derived from the
\[sender]_handshake_traffic_secret.
\[sender]_handshake_traffic_secret,
except for post-handshake authentication.

The computations for the Authentication messages all uniformly
take the following inputs:
Expand Down Expand Up @@ -2930,7 +2931,7 @@ for each scenario:
|------|-------------------|----------|
| Server | ClientHello ... later of EncryptedExtensions/CertificateRequest | server_handshake_traffic_secret |
| Client | ClientHello ... later of server Finished/EndOfEarlyData | client_handshake_traffic_secret |
| Post-Handshake | ClientHello ... client Finished + CertificateRequest | client_application_traffic_secret_N |
| Post-Handshake | ClientHello ... client Finished + CertificateRequest | [sender]_application_traffic_secret_N |
{: #hs-ctx-and-keys title="Authentication Inputs"}

### The Transcript Hash
Expand Down Expand Up @@ -3129,9 +3130,8 @@ If the server cannot produce a certificate chain that is signed only via the
indicated supported algorithms, then it SHOULD continue the handshake by sending
the client a certificate chain of its choice that may include algorithms
that are not known to be supported by the client.
This fallback chain SHOULD NOT use the deprecated SHA-1 hash algorithm in general,
but MAY do so if the client's advertisement permits it,
and MUST NOT do so otherwise.
This fullback chain MUST NOT use the deprecated SHA-1 hash,
except if advertised by the client, in which case it MAY.

If the client cannot construct an acceptable chain using the provided
certificates and decides to abort the handshake, then it MUST abort the
Expand Down Expand Up @@ -3379,7 +3379,8 @@ appropriate application traffic key.

### New Session Ticket Message {#NSTMessage}

At any time after the server has received the client Finished message,
At any time after the server has received both a "psk_key_exchange_modes" extension
and the client Finished message,
Comment on lines +3382 to +3383
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
At any time after the server has received both a "psk_key_exchange_modes" extension
and the client Finished message,
If the client's hello contained a suitable "psk_key_exchange_modes" extension, at any time after the server has received the client Finished message,

it MAY send a NewSessionTicket message. This message creates a unique
association between the ticket value and a secret PSK
derived from the resumption secret (see {{cryptographic-computations}}).
Expand Down Expand Up @@ -4081,8 +4082,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
Loading