RFC Errata
Found 43 records.
Status: Verified (12)
RFC 8446, "The Transport Layer Security (TLS) Protocol Version 1.3", August 2018
Source of RFC: tls (sec)
Errata ID: 5483
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Patrick Kelsey
Date Reported: 2018-08-28
Verifier Name: Paul Wouters
Date Verified: 2024-03-29
Section 4.2.8.2 says:
For X25519 and X448, the contents of the public value are the byte string inputs and outputs of the corresponding functions defined in [RFC7748]: 32 bytes for X25519 and 56 bytes for X448.
It should say:
For X25519 and X448, the contents of the public value are the byte string outputs of the corresponding functions defined in [RFC7748]: 32 bytes for X25519 and 56 bytes for X448.
Notes:
Per Section 7.4.2 of this RFC and Section 6 of RFC7748, the byte string inputs to the corresponding ECDH scalar multiplication function are the private key and the u-coordinate of the standard public base point, the former of which of course must not be transmitted and the latter of which is a known constant.
Paul Wouters (AD): Resolved but with the following Corrected Text:
For X25519 and X448, the contents of the public value is the K_A or
K_B value described in Section 6 of [RFC7748]. This is 32 bytes for
X25519 and 56 bytes for X448.
From another perspective, including the byte string inputs in the contents of the public value would contradict the resulting content sizes given at the end of the cited paragraph as well as the statement in Section 7.4.2 that the public key put into the KeyShareEntry is the output of ECDH scalar multiplication function.
Errata ID: 5868
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Hubert Kario
Date Reported: 2019-10-02
Verifier Name: Paul Wouters
Date Verified: 2024-03-21
Section 4.2.3 says:
ECDSA algorithms: Indicates a signature algorithm using ECDSA
[ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA]
and FIPS 186-4 [DSS], and the corresponding hash algorithm as
defined in [SHS]. The signature is represented as a DER-encoded
[X690] ECDSA-Sig-Value structure.
It should say:
ECDSA algorithms: Indicates a signature algorithm using ECDSA
[ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA]
and FIPS 186-4 [DSS], and the corresponding hash algorithm as
defined in [SHS]. The signature is represented as a DER-encoded
[X690] ECDSA-Sig-Value structure as defined in [RFC4492].
Notes:
There is a possibility for confusion as the ECDSA-Sig-Value has two conflicting definitions in authoritative standards. TLS always used the following (see RFC4492):
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
but the publicly accessible SECG SEC1 v2.0 (https://www.secg.org/sec1-v2.pdf) defines it like this:
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER,
a INTEGER OPTIONAL,
y CHOICE { b BOOLEAN, f FieldElement } OPTIONAL
}
I think using the RFC5480 in the Corrected Text would be cleaner than RFC4492, but the former is not an existing reference, so we would need to update section 12 also.
Errata ID: 6123
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-24
Verifier Name: Paul Wouters
Date Verified: 2024-03-29
Section 2 says:
The handshake protocol allows peers to negotiate a protocol version, select cryptographic algorithms, optionally authenticate each other, and establish shared secret keying material.
Notes:
Only client authentication is optional (albeit, server authentication is implicit for PSK-only key exchange mode)
Paul Wouters(AD): corrected with the following text:
The handshake protocol allows peers to negotiate a protocol version, select cryptographic algorithms, authenticate each other (with client authentication being optional), and establish shared secret keying material.
Errata ID: 6142
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29
Verifier Name: Paul Wouters
Date Verified: 2024-03-21
Section 4.6.1. says:
Clients MUST NOT cache tickets for longer than 7 days
It should say:
Clients MUST NOT use tickets for longer than 7 days
Notes:
"MUST NOT cache" is surely overly zealous and may unnecessarily result in non-compliant implementations
Errata ID: 6146
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29
Verifier Name: Paul Wouters
Date Verified: 2024-03-21
Section 4.2.10. says:
The TLS version number
It should say:
The selected TLS version number
Errata ID: 7303
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eric Lawrence
Date Reported: 2023-01-12
Verifier Name: Paul Wouters
Date Verified: 2024-03-29
Section 6.1 says:
This alert notifies the recipient that the sender will not send any more messages on this connection.
It should say:
This alert notifies the recipient that the sender will not send any more messages on this connection. close_notify alerts should be sent with a severity level of WARNING.
Notes:
Apparently, TLS/1.0 specified these should be set to WARNING, not FATAL, but this text got lost somewhere along the way. https://github.com/pion/dtls/issues/195
OpenSSL/NSS both send as WARNING, and servers that have tried sending as FATAL have encountered compatibility problems with clients which treat FATAL alerts differently than WARNING alerts: e.g. https://source.chromium.org/chromium/chromium/src/+/main:third_party/boringssl/src/ssl/tls_record.cc;l=591;drc=c0872c02015009bf3dbab0a83c0452d141e8e9cf?q=tls_open_record&ss=chromium%2Fchromium%2Fsrc
Paul Wouters(AD): Resolved but with the following Corrected Text:
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. This alert MUST be sent with AlertLevel=warning.
Errata ID: 7250
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2022-11-14
Verifier Name: Paul Wouters
Date Verified: 2024-03-29
Section 4.6.1 says:
The client MAY use this PSK for future handshakes by including the ticket value in the "pre_shared_key" extension in its ClientHello (Section 4.2.11).
It should say:
(to add) Where the client does not support session tickets, this extension MUST be ignored.
Notes:
I've seen a TLS implementation which doesn't implement session tickets. That's fine, but the implementation doesn't *ignore* session tickets it receives. Instead, it treats reception of the ticket as un recoverable error, and drops the TLS connection.
It's also worth adding a note to section 4.2 at the bottom of page 38. To note that in general, f an extension isn't supported AND doesn't materially affect the TLS exchange, THEN it should be ignored.
i.e. there's nothing in the spec which mentions Postel's law "be conservative in what you send, be liberal in what you accept". So implementors reading this document are free to do all kinds of odd things.
In addition, the text in Section 4.2 at the bottom of page 38 says:
"
Designers
and implementors should be aware of the fact that until the
handshake has been authenticated, active attackers can modify
messages and insert, remove, or replace extensions.
"
The implicit conclusion here is that an implementation receiving extensions must sanity check them. e.g. an attacker adding an undefined / unknown extension should not cause the entire session to be torn down.
Paul Wouters(AD): Resolved but with the Corrected Text:
The client MAY use this PSK for future handshakes by including the ticket value in the "pre_shared_key" extension in its ClientHello (Section 4.2.11). Clients which receive a NewSessionTicket message but do not support resumption MUST silently ignore this message.
Errata ID: 5976
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rich Salz
Date Reported: 2020-02-04
Verifier Name: Benjamin Kaduk
Date Verified: 2020-03-07
Section 11 says:
This document updates an entry in the TLS Certificate Types registry originally created in [RFC6091] and updated in [RFC8447]. IANA has updated the entry for value 1 to have the name "OpenPGP_RESERVED", "Recommended" value "N", and comment "Used in TLS versions prior to 1.3."
It should say:
This document updates two entries in the TLS Certificate Types registry originally created in [RFC6091] and updated in [RFC8447]. IANA has updated the entry for value 1 to have the name "OpenPGP_RESERVED", "Recommended" value "N", and comment "Used in TLS versions prior to 1.3." IANA has updated the entry for value 0 to have the name "X509", "Recommended" value "Y", and comment "Was X.509 before TLS 1.3".
Notes:
The protocol description language changed the spelling used for "X509", and the registry should be updated to match.
Errata ID: 6122
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-24
Verifier Name: Paul Wouters
Date Verified: 2024-03-21
Section 1.2 says:
The key derivation functions have been redesigned.
It should say:
The key derivation function has been redesigned.
Errata ID: 6139
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29
Verifier Name: Paul Wouters
Date Verified: 2024-03-29
Section 4.4.2.2. says:
As servers MAY require the presence of the "server_name" extension, clients SHOULD send this extension, when applicable.
It should say:
As servers MAY require the presence of the "server_name" extension, client SHOULD send this extension.
Notes:
Since it is unclear when it is applicable for a server to send the extension, dropping "when applicable"
seems appropriate. Alternatively, giving some extra guidance would be useful.
Paul Wouters(AD): Resolved with alternative Corrected Text:
As servers MAY require the presence of the "server_name" extension, clients SHOULD send this extension when the server is identified by name.
Errata ID: 6141
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29
Verifier Name: Paul Wouters
Date Verified: 2024-03-21
Section 4.4.3 says:
- The context string
It should say:
- The context string (defined below)
Errata ID: 7774
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rebecca VanRheenen
Date Reported: 2024-01-22
Verifier Name: RFC Editor
Date Verified: 2024-01-22
Section 4.1.3 says:
ServerHello.Random
It should say:
ServerHello.random
Notes:
Lowercase "random".
This report was created/verified per Paul Wouter's note at https://www.rfc-editor.org/errata/eid7769.
Status: Held for Document Update (18)
RFC 8446, "The Transport Layer Security (TLS) Protocol Version 1.3", August 2018
Source of RFC: tls (sec)
Errata ID: 5682
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Barnes
Date Reported: 2019-04-01
Held for Document Update by: Paul Wouters
Date Held: 2024-01-17
Section 4.3.2, B.3.2 says:
struct {
opaque certificate_request_context<0..2^8-1>;
Extension extensions<2..2^16-1>;
} CertificateRequest;
It should say:
struct {
opaque certificate_request_context<0..2^8-1>;
Extension extensions<0..2^16-1>;
} CertificateRequest;
Notes:
The length of this vector can never 2. It is either 0, if the vector is empty, or >=4, if the vector has at least one extension. Nothing elsewhere in the spec requires a non-zero number of extensions here, so this syntax should allow a zero-length vector.
Paul Wouters (AD): There are two places in the mentioned sections that need this one liner fix.
Errata ID: 5874
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mr Laurie Perrin
Date Reported: 2019-10-12
Held for Document Update by: Paul Wouters
Date Held: 2024-04-05
Section 5.1 says:
... Application Data messages contain data that is opaque to TLS. Application Data messages are always protected. Zero-length fragments of Application Data MAY be sent, as they are potentially useful as a traffic analysis countermeasure. Application Data fragments MAY be split across multiple records or coalesced into a single record.
It should say:
... Application Data messages contain data that is opaque to TLS. Application Data messages are always protected. Zero-length fragments of Application Data (i.e. those encapsulating an TLSInnerPlaintext record having a content field of length zero) MAY be sent, as they are potentially useful as a traffic analysis countermeasure. Application Data fragments MAY be split across multiple records or coalesced into a single record.
Notes:
In the interest of clarity, it may be prudent to specify the type of record for
which a fragment of length zero is being considered - it cannot be that of the
TLSCiphertext itself, for "Application Data messages are always protected,"
therefore I infer this relates to the TLSInnerPlaintext content field (of
length "TLSPlaintext.length") - i.e. to the TLSPlaintext fragment.
Note: This comment also applies to previous versions of the TLS specification,
in particular with the introduction of the respective text concerning zero-length
fragments in RFC 5246. In TLS 1.2, this would be the GenericXXCipher content
field of length "TLSCompressed.length" - i.e. to the TLSCompressed fragment.
Note: The implications of zero-length records must be considered with respect to
potential vectors for denial of service.
Paul Wouters(AD): Currently discussed at:
https://github.com/tlswg/tls13-spec/issues/1346
https://github.com/tlswg/tls13-spec/pull/1347
Errata ID: 6136
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-28
Held for Document Update by: Paul Wouters
Date Held: 2024-10-17
Section 4.1.4 says:
Upon receipt of a HelloRetryRequest, the client MUST check the legacy_version, legacy_session_id_echo, cipher_suite, and legacy_compression_method as specified in Section 4.1.3
Notes:
Section 4.1.3 defines no checks for legacy_version nor legacy_compression_method
--VERIFIER NOTES--
It does have the listed fields and values it should contain (to check) in the previous 4.1.3 section.
This is being addressed; see https://github.com/tlswg/tls13-spec/pull/1364/files
Errata ID: 6140
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29
Held for Document Update by: Paul Wouters
Date Held: 2024-10-17
Section 4.4.2.2. says:
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.
It should say:
This fullback chain MUST NOT use the deprecated SHA-1 hash, except if advertised by the client, in which case it MAY.
Notes:
The original text is difficult to read, eliminating the unnecessary "SHOULD NOT" seems to make it
easier.
Paul Wouters(SEC AD): accepted with slightly different text, keeping the SHOULD NOT -> MUST NOT change proposed here
Errata ID: 6151
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-30
Held for Document Update by: Paul Wouters
Date Held: 2024-10-17
Section 4.4 says:
| Post- | ClientHello ... client | client_application_traffic_ | | Handshake | Finished + | secret_N | | | CertificateRequest | |
It should say:
| Post- | ClientHello ... client | [sender]_application_traffic| | Handshake | Finished + | _secret_N | | | CertificateRequest | |
Errata ID: 6401
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Eric Covener
Date Reported: 2021-01-20
Held for Document Update by: Paul Wouters
Date Held: 2024-03-29
Section 4.6.2 says:
When the client has sent the "post_handshake_auth" extension (see Section 4.2.6), a server MAY request client authentication at any time after the handshake has completed by sending a CertificateRequest message.
It should say:
When the client has sent the "post_handshake_auth" extension (see Section 4.2.6), a server MAY request client authentication during the main handshake and/or at any time after the handshake has completed by sending a CertificateRequest message.
Notes:
4.6.2 is ambiguous as to whether it forbids "main handshake" (mid-handshake) client
authentication when the client has sent the "post_handshake_auth" extension. I think
the language would be stronger if it were really forbidden, and openssl s_server permits
this behavior and rfc8740 implies it as well.
The "main handshake" language is adopted from 4.3.2 but "main" could be dropped as
"handshake" is not ambiguous in 1.3 due to no renegotiation.
Errata ID: 6820
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Leander Schwarz
Date Reported: 2022-01-21
Held for Document Update by: Paul Wouters
Date Held: 2024-04-05
Section 6.2 says:
unsupported_extension: Sent by endpoints receiving any handshake
message containing an extension known to be prohibited for
inclusion in the given handshake message, or including any
extensions in a ServerHello or Certificate not first offered in
the corresponding ClientHello or CertificateRequest.
It should say:
unsupported_extension: Sent by endpoints receiving any handshake
message containing an extension in a ServerHello or Certificate
not first offered in the corresponding ClientHello or
CertificateRequest.
Notes:
The definition of the unsupported_extension alert in section 6.2 contradicts the statements in section 4.2:
If an implementation receives an extension
which it recognizes and which is not specified for the message in
which it appears, it MUST abort the handshake with an
"illegal_parameter" alert.
While this might not be inconsistent due to the "abort the handshake with an X alert" specification at the beginning of section 6.2, it might lead to confusion. (see https://mailarchive.ietf.org/arch/msg/tls/hGOGWZRMg718mWqOZ06LwjV9360/).
Paul Wouters(AD): Currently discussed at:
https://github.com/tlswg/tls13-spec/issues/1352
https://github.com/tlswg/tls13-spec/pull/1353
Errata ID: 7003
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2022-06-22
Held for Document Update by: Paul Wouters
Date Held: 2024-10-17
Section 4.6.1. says:
At any time after the server has received the client Finished message, it MAY send a NewSessionTicket message.
It should say:
At any time after the server has received both a "psk_key_exchange_modes" extension and a Finished message, it MAY send a NewSessionTicket message.
Notes:
Section 4.2.9. demands
In order to use PSKs, clients MUST also send a "psk_key_exchange_modes" extension.
Hence, an additional restriction is needed in Section 4.6.1.
Errata ID: 7073
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2022-08-06
Held for Document Update by: Paul Wouters
Date Held: 2024-10-17
Section 4.4 says:
These messages are encrypted under keys derived from the [sender]_handshake_traffic_secret.
It should say:
These messages are encrypted under keys derived from the [sender]_handshake_traffic_secret, except for post-handshake authentication
Notes:
There's an exception
Errata ID: 5627
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Kahn Gillmor
Date Reported: 2019-02-08
Held for Document Update by: Benjamin Kaduk
Date Held: 2019-02-08
Section 4.2.11 says:
In TLS versions prior to TLS 1.3, the Server Name Identification (SNI) value
It should say:
In TLS versions prior to TLS 1.3, the Server Name Indication (SNI) value
Notes:
RFC 6066 and many other places indicate that the correct expansion for "SNI" is "Server Name Indication", not "Server Name Identification".
Errata ID: 5717
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Daniel Migault
Date Reported: 2019-05-03
Held for Document Update by: Paul Wouters
Date Held: 2024-03-29
Section 2.2. says:
Figure 3 shows a pair of handshakes in which the first handshake
establishes a PSK and the second handshake uses it:
Client Server
Initial Handshake:
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
<-------- [NewSessionTicket]
[Application Data] <-------> [Application Data]
Subsequent Handshake:
ClientHello
+ key_share*
+ pre_shared_key -------->
ServerHello
+ pre_shared_key
+ key_share*
{EncryptedExtensions}
{Finished}
<-------- [Application Data*]
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 3: Message Flow for Resumption and PSK
It should say:
Figure 3 shows a pair of handshakes in which the first handshake
establishes a PSK and the second handshake uses it:
Client Server
Initial Handshake:
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
<-------- [NewSessionTicket]
[Application Data] <-------> [Application Data]
Subsequent Handshake:
ClientHello
+ key_share*
+ psk_key_exchange_modes
+ pre_shared_key -------->
ServerHello
+ pre_shared_key
+ key_share*
{EncryptedExtensions}
{Finished}
<-------- [Application Data*]
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 3: Message Flow for Resumption and PSK
Notes:
The pre_shared_key requires the pre_share_key extension.
This Issue and PR should address this erratum:
https://github.com/tlswg/tls13-spec/issues/1344
https://github.com/tlswg/tls13-spec/pull/1345
Errata ID: 6125
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-24
Held for Document Update by: Paul Wouters
Date Held: 2024-03-21
Throughout the document, when it says:
PSKs are referred to as out-of-band and external
It should say:
Referring to PSKs as either out-of-band xor external would help at least one reader
Notes:
This got incorporated into the bis document, but not exactly as suggested.
Errata ID: 6128
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-24
Held for Document Update by: Paul Wouters
Date Held: 2024-03-21
Throughout the document, when it says:
terminate and abort are used interchangeable, but this isn't explained until after such use. In Section 6.2, we have: In the rest of this specification, when the phrases "terminate the connection" and "abort the handshake" are used without a specific alert it means that the implementation SHOULD send the alert indicated by the descriptions below.
It should say:
Perhaps explain terminology earlier. At the very least, in Section 6.2, open the above sentence with "Throughout this specification"
Notes:
This got incorporated into the bis document, but not exactly as suggested.
Errata ID: 6135
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-28
Held for Document Update by: Paul Wouters
Date Held: 2024-03-21
Section Global says:
list, series, set, and vector are seemingly used as synonyms.
It should say:
Using list, series, set, xor vector would help at least one reader.
Notes:
Additionally, consistent usage is desirable, e.g., page 31 uses "A list of extensions" whereas "A set of
extensions" is used on page 60. Elsewhere inconsistently usage causes confusion, e.g.,
Page 48:
client_shares: A list of offered KeyShareEntry values in descending
order of client preference.
This vector MAY be empty if the client is requesting a
(Replace "vector" with "list", or vice versa.)
Paul Wouters (AD): This got incorporated into the bis document, but not exactly as suggested.
Errata ID: 6138
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-28
Held for Document Update by: Paul Wouters
Date Held: 2024-03-21
Section 4.2.10 says:
For externally provisioned PSKs, the associated values are those provisioned along with the key. For PSKs established via a NewSessionTicket message, the associated values are those which were negotiated in the connection which established the PSK. ... For externally established PSKs, the associated values are those provisioned along with the key. For PSKs established via a NewSessionTicket message, the associated values are those negotiated in the connection during which the ticket was established.
It should say:
For externally provisioned PSKs, the associated values are those provisioned along with the key. For PSKs established via a NewSessionTicket message, the associated values are those which were negotiated in the connection which established the PSK.
Notes:
Drop largely verbatim duplicated text
Paul Wouters (AD): This got incorporated into the bis document, but not exactly as suggested.
Errata ID: 6147
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29
Held for Document Update by: Paul Wouters
Date Held: 2024-10-17
Section 4.2.10. says:
In order to accept early data, the server MUST have accepted a PSK cipher suite....In addition, it MUST verify that the following values are the same as those associated with the selected PSK: ... - The selected cipher suite
Notes:
Accepting the "PSK cipher suite" surely implies the PSK is associated with the cipher suite, hence,
"The selected cipher suite" can be dropped.
Paul Wouters(SEC AD): The text was changed a little to solve this issue
Errata ID: 6204
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Chris Wood
Date Reported: 2020-06-03
Held for Document Update by: Paul Wouters
Date Held: 2024-03-29
Section E.1 says:
Implementations MUST NOT combine external PSKs with certificate-based authentication of either the client or the server unless negotiated by some extension.
It should say:
Implementations MUST NOT combine external PSKs with certificate-based authentication of either client or the server. Future specifications MAY provide an extension to permit this.
Notes:
The existing text can be misread as permitting this combination upon negotiation of the "post_handshake_auth" extension, which would be incorrect. [1] describes an attack that can occur based on this misinterpretation. The proposed text aims to make clear that a *new* extension is required for this combination.
Paul Wouters(AD): See https://mailarchive.ietf.org/arch/msg/tls/uDjERicvcTimiecyhiSrYA0H1Sc/
[1] https://link.springer.com/article/10.1007%2Fs11416-020-00352-0
Errata ID: 6205
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2020-06-04
Held for Document Update by: Paul Wouters
Date Held: 2024-01-17
Section 4.3.2 says:
Servers which are authenticating with a PSK MUST NOT send the CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see Section 4.6.2) provided that the client has sent the "post_handshake_auth" extension (see Section 4.2.6).
It should say:
Servers which are authenticating with a resumption PSK MUST NOT send the CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see Section 4.6.2) provided that the client has sent the "post_handshake_auth" extension (see Section 4.2.6). Servers which are authenticating with an external PSK MUST NOT send the CertificateRequest message either in the main handshake or request post-handshake authentication. Future specifications MAY provide an extension to permit this.
Notes:
The lack of qualification on "authenticating with a PSK" implies that the statement applies equally to both external and resumption PSKs. However, there are two conditions being governed: whether a certificate can be requested during the handshake, and whether a certificate can be requested post-handshake. The latter of these requires different rules depending on the type of PSK.
We know from the analysis of resumption (see https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/) that combining a PSK handshake of either type with a client certificate is not safe. Thus, the prohibition on CertificateRequest during the handshake applies equally to both resumption and external PSKs.
For post-handshake, Appendix E.1 already discusses the risks of combining PSKs with certificates, citing the same analysis as above.
[...] It is unsafe to use certificate-based client
authentication when the client might potentially share the same
PSK/key-id pair with two different endpoints.
For this reason an external PSK is not safe to use with post-handshake authentication. A resumption PSK does not have this property, so the same prohibition doesn't apply.
Splitting the requirements as proposed makes this split clearer.
Status: Rejected (13)
RFC 8446, "The Transport Layer Security (TLS) Protocol Version 1.3", August 2018
Source of RFC: tls (sec)
Errata ID: 6143
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29
Rejected by: Paul Wouters
Date Rejected: 2024-10-17
Section 4.2.7 says:
As of TLS 1.3, servers are permitted to send the "supported_groups" extension to the client.
Notes:
It is unclear whether servers are permitted to send the "supported_groups" extension to
the client without solicitation, i.e., when the client does not first send the extension to the
server. Clarification would be useful.
--VERIFIER NOTES--
rejected by WG
Errata ID: 6145
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29
Rejected by: Paul Wouters
Date Rejected: 2024-10-17
Section 4.2.10. says:
When a PSK is used and early data is allowed for that PSK
Notes:
I couldn't find restrictions that forbid early data for a PSK. Explaining where such restrictions
could exist would be useful. E.g., PSKs might be associated with data that forbids early data.
--VERIFIER NOTES--
rejected by WG
Errata ID: 6152
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-05-01
Rejected by: Paul Wouters
Date Rejected: 2024-10-17
Section 4 says:
Clients MUST check for ["supported_versions"] prior to processing the rest of the ServerHello (although they will have to parse the ServerHello in order to read the extension). -- Section 4.2.1. Upon receipt of a HelloRetryRequest, the client MUST check the legacy_version, legacy_session_id_echo, cipher_suite, and legacy_compression_method as specified in Section 4.1.3 and then process the extensions, starting with determining the version using "supported_versions". -- Section 4.1.4 Upon receiving a message with type server_hello, implementations MUST first examine the Random value... -- Section 4.1.3.
Notes:
These requirements are seemingly conflicting. I suspect checking for "supported_versions" must
come first, since that may influence subsequent steps, e.g., checking legacy_compression_method
and the Random value. It doesn't seem to matter whether legacy_version, legacy_session_id_echo,
cipher_suite, and legacy_compression_method are checked before the Random value, so it doesn't
seem to matter which check is second and which is third. (Noting, as per one of my earlier reports,
dated 28 Apr, Section 4.1.3 defines no checks for legacy_version nor legacy_compression_method.
Perhaps the latter should be checked to be zero, aborting with alert illegal_parameter if it isn't, as per
Section 4.1.2.)
--VERIFIER NOTES--
rejected by WG
Errata ID: 7620
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2023-08-28
Rejected by: Paul Wouters
Date Rejected: 2024-10-17
Section 6.1 says:
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.
It should say:
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 SHOULD NOT have any effect on the read side of the sender's connection; 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 wait to receive a "close_notify" alert before closing their read side of the connection, though doing so would introduce the possibility of truncation.
Notes:
As-is there's a specification-level vulnerability: Specification-compliant implementations may be vulnerable to truncation attacks.
I suggest using SHOULD NOT & SHOULD for better signposting and to avoid specification-level vulnerability.
I also suggest minor tweaks for readability.
--VERIFIER NOTES--
Rejected by WG. See https://github.com/tlswg/tls13-spec/pull/1357/commits/d2a36a8029067cb20ff431fcaa8b3a4e537e4bf6
Errata ID: 6120
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-24
Rejected by: Paul Wouters
Date Rejected: 2024-10-17
Section 1 says:
the underlying transport is a reliable, in-order data stream
It should say:
the underlying transport layer is a reliable, in-order stream delivery service or the underlying transport protocol is a reliable, in-order stream delivery service or similar
Notes:
Similar elsewhere
--VERIFIER NOTES--
rejected by WG.
Errata ID: 6121
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-24
Rejected by: Paul Wouters
Date Rejected: 2024-10-17
Section 1 says:
cryptographic modes
It should say:
cryptographic algorithms
Notes:
--VERIFIER NOTES--
rejected by WG
Errata ID: 6124
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-24
Rejected by: Paul Wouters
Date Rejected: 2024-10-17
Section 2 says:
In the Key Exchange phase, the client sends the ClientHello (Section 4.1.2) message, which contains a random nonce (ClientHello.random); its offered protocol versions; a list of symmetric cipher/HKDF hash pairs; either a set of Diffie-Hellman key shares (in the "key_share" (Section 4.2.8) extension), a set of pre-shared key labels (in the "pre_shared_key" (Section 4.2.11) extension), or both; and potentially additional extensions.
It should say:
In the Key Exchange phase, the client sends the ClientHello (Section 4.1.2) message, which contains a random nonce (ClientHello.random); its offered protocol versions; a list of symmetric cipher/Hash algorithm pairs; either a set of Diffie-Hellman key shares (in the "key_share" (Section 4.2.8) extension), a set of pre-shared key labels (in the "pre_shared_key" (Section 4.2.11) extension), or both; and potentially additional extensions. or In the Key Exchange phase, the client sends the ClientHello (Section 4.1.2) message, which contains a random nonce (ClientHello.random); its offered protocol versions; a list of symmetric cipher/Hash algorithm (to be used with HKDF) pairs; either a set of Diffie-Hellman key shares (in the "key_share" (Section 4.2.8) extension), a set of pre-shared key labels (in the "pre_shared_key" (Section 4.2.11) extension), or both; and potentially additional extensions.
Notes:
--VERIFIER NOTES--
rejected by WG
Errata ID: 6126
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-24
Rejected by: Paul Wouters
Date Rejected: 2024-10-17
Section 4.1.1 says:
Note that if the PSK can be used without (EC)DHE, then non-overlap in the "supported_groups" parameters need not be fatal, as it is in the non-PSK case discussed in the previous paragraph.
It should say:
Note that if the PSK can be used without (EC)DHE, then non-overlap in the "supported_groups" parameters need not be fatal, as it is in the non-PSK case discussed in the previous paragraph, because PSK-only key exchange mode does not need supported_groups.
Notes:
If "the PSK can be used without (EC)DHE", then PSK-only key exchange mode can be used, which doesn't require supported_groups. This is perhaps worthy of explanation.
--VERIFIER NOTES--
rejected by WG
Errata ID: 6127
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-24
Rejected by: Paul Wouters
Date Rejected: 2024-10-17
Section 4.1.2. says:
If a "key_share" extension was supplied in the HelloRetryRequest, replacing the list of shares with a list containing a single KeyShareEntry from the indicated group.
It should say:
If a "key_share" extension was supplied in the HelloRetryRequest, replacing the list of shares with a list containing a single KeyShareEntry from the indicated group. Note: A "key_share" extension may not be supplied in a HelloRetryRequest message when a server receives an "early_data" (Section 4.2.10).
Notes:
--VERIFIER NOTES--
rejected by WG
Errata ID: 6137
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-28
Rejected by: Paul Wouters
Date Rejected: 2024-10-17
Section 4.2.10 says:
symmetric cipher suite
It should say:
cipher suite
Notes:
--VERIFIER NOTES--
rejected by WG
Errata ID: 6144
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29
Rejected by: Paul Wouters
Date Rejected: 2024-10-17
Section 4.2.8. says:
Upon receipt of this extension in a HelloRetryRequest, the client MUST verify that...the selected_group field does not correspond to a group which was provided in the "key_share" extension in the original ClientHello.
It should say:
Upon receipt of this extension in a HelloRetryRequest, the client MUST verify that...a key share was not offered (in the "key_share" extension in the original ClientHello) for the group in the selected_group field.
Notes:
The original text requires knowledge of the "key_share" extension and is rather hard to read,
the proposed text should be easier to understand.
--VERIFIER NOTES--
rejected by WG
Errata ID: 6148
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29
Rejected by: Paul Wouters
Date Rejected: 2024-10-17
Section 4.2.10 says:
The selected ALPN [RFC7301] protocol, if any
It should say:
The selected ALPN [RFC7301] protocol, if extension application_layer_protocol_negotiation is present
Notes:
--VERIFIER NOTES--
rejected by WG
Errata ID: 6150
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2020-04-29
Rejected by: Paul Wouters
Date Rejected: 2024-10-17
Throughout the document, when it says:
Note that certificate-based client authentication is not available in PSK handshake flows (including 0-RTT).
It should say:
Note that certificate-based client authentication is not available in PSK handshake flows (including 0-RTT), post-handshake certificate-based client authentication is possible.
Notes:
--VERIFIER NOTES--
rejected by WG