Addressing erratum #1357
Addressing erratum #1357
Conversation
|
For future reference, individual PRs would have been more helpful here :) |
| @@ -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 | |||
There was a problem hiding this comment.
I don't believe this, and by extension Erratum 6152, is correct. The order of operations is:
- Look at SH.Random to determine if it's actually an HRR
- If it is a HRR, then follow the HRR processing steps described in 4.1.4.
- If it a SH, then follow the SH processing steps described in 4.2.1.
| At any time after the server has received both a "psk_key_exchange_modes" extension | ||
| and the client Finished message, |
There was a problem hiding this comment.
| 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, |
| @@ -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; | |||
There was a problem hiding this comment.
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" .
No description provided.