RFC Errata
Found 5 records.
Status: Verified (2)
RFC 8422, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", August 2018
Note: This RFC has been updated by RFC 8996
Source of RFC: tls (sec)
Errata ID: 5703
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Theinen
Date Reported: 2019-04-23
Verifier Name: Benjamin Kaduk
Date Verified: 2019-05-01
Section 5.10. says:
All RSA signatures must be generated and verified according to Section 7.2 of [RFC8017].
It should say:
All RSA signatures must be generated and verified according to Section 8.2 of [RFC8017].
Notes:
Section 7.2 of RFC 8017 describes the RSAES-PKCS1-v1_5 encryption scheme. Section 8.2 of RFC 8017 describes the RSASSA-PKCS1-v1_5 signature scheme. The original text contradicts the natural expectation and is probably wrong. If it was intended, there should have been a thorough explanation (like in the well-known case of IKEv1 using the encryption scheme for signing).
Errata ID: 6002
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Rich Salz
Date Reported: 2020-03-02
Verifier Name: Benjamin Kaduk
Date Verified: 2020-03-05
Section 9 says:
IANA has assigned two values in the "TLS SignatureAlgorithm" registry for ed25519 (7) and ed448 (8) with this document as reference. This keeps compatibility with TLS 1.3.
It should say:
IANA has assigned two values in the "TLS SignatureAlgorithm" registry for ed25519 (7) and ed448 (8) with DTLS-OK set to "Y" and this document as reference. This keeps compatibility with TLS 1.3.
Notes:
IANA had consulted with Yoav, one of the authors (and a TLS registry expert), who explicitly told them to use DTLS-OK of "Y", but this clarification was not reflected in the final RFC. This also matches the text in the subsequent paragraph.
Status: Reported (1)
RFC 8422, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", August 2018
Note: This RFC has been updated by RFC 8996
Source of RFC: tls (sec)
Errata ID: 8179
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: warren.wang
Date Reported: 2024-11-16
Section 5.4. Server Key Exc says:
The ServerKeyExchange message is extended as follows.
enum {
ec_diffie_hellman
} KeyExchangeAlgorithm;
o ec_diffie_hellman: Indicates the ServerKeyExchange message
contains an ECDH public key.
select (KeyExchangeAlgorithm) {
case ec_diffie_hellman:
ServerECDHParams params;
Signature signed_params;
} ServerKeyExchange;
.....................................................
enum {
ecdsa(3),
ed25519(7)
ed448(8)
} SignatureAlgorithm;
select (SignatureAlgorithm) {
case ecdsa:
digitally-signed struct {
opaque sha_hash[sha_size];
};
case ed25519,ed448:
digitally-signed struct {
opaque rawdata[rawdata_size];
};
} Signature;
ServerKeyExchange.signed_params.sha_hash
SHA(ClientHello.random + ServerHello.random +
ServerKeyExchange.params);
ServerKeyExchange.signed_params.rawdata
ClientHello.random + ServerHello.random +
ServerKeyExchange.params;
NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange
algorithm and "anonymous" for ECDH_anon. These cases are defined in
TLS. SignatureAlgorithm is "ecdsa" or "eddsa" for ECDHE_ECDSA.
It should say:
The extended ServerKeyExchange message seems just for tls version 1.0 and version 1.1, not for 1.2, because tls version 1.2 ServerKeyExchange message format is different from version 1.0 and 1.1. The following is tls version 1.2 ServerKeyExchange message format:
struct {
select (KeyExchangeAlgorithm) {
case dh_anon:
ServerDHParams params;
case dhe_dss:
case dhe_rsa:
ServerDHParams params;
digitally-signed struct {
opaque client_random[32];
opaque server_random[32];
ServerDHParams params;
} signed_params;
case rsa:
case dh_dss:
case dh_rsa:
struct {} ;
/* message is omitted for rsa, dh_dss, and dh_rsa */
/* may be extended, e.g., for ECDH -- see [TLSECC] */
};
} ServerKeyExchange;
it does not specify the message format for ECDH_RSA and ECDH_anon, the "NOTE" in original text does not apply to tls version 1.2, because it doesn't have the "Signature" field.
Notes:
the ServerKeyExchange for ECDH_RSA and ECDH_anon should be specified for tls version 1.2.
Status: Held for Document Update (2)
RFC 8422, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", August 2018
Note: This RFC has been updated by RFC 8996
Source of RFC: tls (sec)
Errata ID: 5466
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Masato Gosui
Date Reported: 2018-08-17
Held for Document Update by: Benjamin Kaduk
Date Held: 2018-08-17
Section 5.3 says:
Actions of the sender: The server constructs an appropriate certificate chain and conveys it to the client in the Certificate message. If the client has used a Supported Elliptic Curves Extension, the public key in the server's certificate MUST respect the client's choice of elliptic curves. A server that cannot satisfy this requirement MUST NOT choose an ECC cipher suite in its ServerHello message.)
It should say:
Actions of the sender: The server constructs an appropriate certificate chain and conveys it to the client in the Certificate message. If the client has used a Supported Elliptic Curves Extension, the public key in the server's certificate MUST respect the client's choice of elliptic curves. A server that cannot satisfy this requirement MUST NOT choose an ECC cipher suite in its ServerHello message.
Notes:
This removes the spurious closing parenthesis of the last sentence of the "Actions of the sender" paragraph.
Errata ID: 5468
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Masato Gosui
Date Reported: 2018-08-17
Held for Document Update by: Paul Wouters
Date Held: 2024-01-17
Section 5.4 says:
namedCurve: Specifies a recommended set of elliptic curve domain
It should say:
namedcurve: Specifies a recommended set of elliptic curve domain
Notes:
This fixes mismatched names of the variable "namedcurve" in the "Structure of this message" paragraph.