|
|
|
|
Found 9 records.
Errata ID: 1585
Status: Verified
Type: Technical
Reported By: Pasi Eronen
Date Reported: 2008-11-05
Verifier Name: Pasi Eronen
Date Verified: 2009-03-02
Section A.4.2 says:
struct {
ClientCertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
It should say:
struct {
ClientCertificateType certificate_types<1..2^8-1>;
SignatureAndHashAlgorithm
supported_signature_algorithms<2^16-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
Notes:
The definition in Section 7.4.4 (which includes the "supported_
signature_algorithms" field) is the correct one (confirmed
by Eric Rescorla on 2009-02-27)
Errata ID: 2643
Status: Verified
Type: Technical
Reported By: Matt McCutchen
Date Reported: 2010-11-22
Verifier Name: Sean Turner
Date Verified: 2011-03-09
Section E.3 says:
When a TLS-capable server negotiates SSL 2.0 it SHOULD, after decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding bytes are 0x03. If they are not, the server SHOULD generate a random value for SECRET-KEY-DATA, and continue the handshake (which will eventually fail since the keys will not match).
It should say:
When a TLS-capable server negotiates SSL 2.0 it SHOULD, after decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding bytes are not all 0x03. If they are, the server SHOULD generate a random value for SECRET-KEY-DATA, and continue the handshake (which will eventually fail since the keys will not match).
Notes:
The condition is the wrong way around. When the bytes *are* all 0x03, that means the client supports TLS, so there must have been a version rollback attack in order for SSL 2.0 to be negotiated. For example, see the NSS implementation (line number may rot):
https://mxr.mozilla.org/mozilla/source/security/nss/lib/ssl/sslcon.c#1695
Errata ID: 2864
Status: Verified
Type: Technical
Reported By: Alfredo Pironti
Date Reported: 2011-07-19
Verifier Name: Sean Turner
Date Verified: 2012-01-09
Section A.4.2 says:
struct {
ClientCertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
--- Fixed by errata 1585 to
struct {
ClientCertificateType certificate_types<1..2^8-1>;
SignatureAndHashAlgorithm
supported_signature_algorithms<2^16-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
It should say:
struct {
ClientCertificateType certificate_types<1..2^8-1>;
SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-2>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
Notes:
The supported_signature_algorithms field is a variable length array. As such ceiling and floor should be specified, and they should be multiple of the base type (which is two bytes long in this case).
Errata ID: 2865
Status: Verified
Type: Technical
Reported By: Alfredo Pironti
Date Reported: 2011-07-19
Verifier Name: Sean Turner
Date Verified: 2012-01-09
Section 7.4.4 says:
struct {
ClientCertificateType certificate_types<1..2^8-1>;
SignatureAndHashAlgorithm
supported_signature_algorithms<2^16-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
It should say:
struct {
ClientCertificateType certificate_types<1..2^8-1>;
SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-2>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
Notes:
The supported_signature_algorithms field is a variable length array. As such ceiling and floor should be specified, and they should be multiple of the base type (which is two bytes long in this case). See section 7.4.1.4.1 for a valid definition of this field.
Errata ID: 3122
Status: Verified
Type: Technical
Reported By: Daniel Otte
Date Reported: 2012-02-16
Verifier Name: Sean Turner
Date Verified: 2012-05-06
Section A.4. says:
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20)
(255)
} HandshakeType;
It should say:
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20),
(255)
} HandshakeType;
Notes:
The comma after finished(20) is missing in the original text.
Errata ID: 3123
Status: Verified
Type: Technical
Reported By: Daniel Otte
Date Reported: 2012-02-16
Verifier Name: Sean Turner
Date Verified: 2012-05-06
Section A.4.2. says:
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 should say:
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;
Notes:
The '};' which belongs to 'select (KeyExchangeAlgorithm) {' is missing in the original text.
Errata ID: 2390
Status: Held for Document Update
Type: Editorial
Reported By: Juho Vähä-Herttua
Date Reported: 2010-07-23
Held for Document Update by: Sean Turner
Section 6.2.3.3 says:
The additional authenticated data, which we denote as
additional_data, is defined as follows:
additional_data = seq_num + TLSCompressed.type +
TLSCompressed.version + TLSCompressed.length;
where "+" denotes concatenation.
The aead_output consists of the ciphertext output by the AEAD
encryption operation. The length will generally be larger than
TLSCompressed.length, but by an amount that varies with the AEAD
cipher. Since the ciphers might incorporate padding, the amount of
overhead could vary with different TLSCompressed.length values. Each
AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
Symbolically,
It should say:
The additional authenticated data, which we denote as
additional_data, is defined as follows:
additional_data = seq_num + TLSCompressed.type +
TLSCompressed.version + TLSCompressed.length;
where "+" denotes concatenation.
The aead_output consists of the ciphertext output by the AEAD
encryption operation. The length will generally be larger than
TLSCompressed.length, but by an amount that varies with the AEAD
cipher. Each AEAD cipher MUST NOT produce an expansion of greater
than 1024 bytes. Symbolically,
Notes:
I suggest leaving the sentence about padding out. The value for TLSCompressed.length is required by additional_data for both encryption and decryption. Therefore, it must be possible to determine the TLSCompressed.length from the ciphertext before decryption.
In practice this is done by subtracting the integrity check value length from the ciphertext length, where the integrity check value length is defined by each AEAD cipher separately. If the cipher incorporates variable padding, it is impossible to calculate the TLSCompressed.length without an explicit value sent for each ciphertext separately. Therefore to avoid confusion, it would be better not to mention anything about padding at all.
(issue discussed on tls@ietf.org and with Eric Rescorla, result of both discussions was that padding in AEAD ciphers doesn't seem to be possible with the current specification)
Errata ID: 2165
Status: Held for Document Update
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2010-04-19
Held for Document Update by: Sean Turner
Section 6.2.3.2 says:
Example: If the block length is 8 bytes, the content length (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes, then the length before padding is 82 bytes (this does not include the Dierks & Rescorla Standards Track [Page 23] RFC 5246 TLS August 2008 IV. Thus, the padding length modulo 8 must be equal to 6 in order to make the total length an even multiple of 8 bytes (the block length). The padding length can be 6, 14, 22, and so on, through 254. If the padding length were the minimum necessary, 6, the padding would be 6 bytes, each containing the value 6. Thus, the last 8 octets of the GenericBlockCipher before block encryption would be xx 06 06 06 06 06 06 06, where xx is the last octet of the MAC.
It should say:
Example: If the block length is 8 bytes, the content length (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes, then the length before padding is 82 bytes (this does not include the Dierks & Rescorla Standards Track [Page 23] RFC 5246 TLS August 2008 IV). Thus, the padding length modulo 8 must be equal to 6 in order to make the total length an even multiple of 8 bytes (the block length). The padding length can be 6, 14, 22, and so on, through 254. If the padding length were the minimum necessary, 6, the padding would be 6 bytes, each containing the value 6. Thus, the last 8 octets of the GenericBlockCipher before block encryption would be xx 06 06 06 06 06 06 06, where xx is the last octet of the MAC.
Errata ID: 3191
Status: Rejected
Type: Editorial
Reported By: Martin Rex
Date Reported: 2012-04-12
Rejected by: Sean Turner
Date Rejected: 2012-04-19
Section Meta-Data says:
Obsoletes: 3268, 4346, 4366 Updates: 4492
It should say:
Updates: 4492
Notes:
"Obsoletes: 4366" is factually incorrect, because it is impossible to implement TLSv1.1 (rfc4346) or TLSv1.0(rfc2246) from the TLSv1.2 spec alone. (IPv6 does not obsolete IPv4 and HTTP/1.1 does not obsolete HTTP/1.0 either).
"Obsoletes: 4366" is factually incorrect, because some of the TLS extensions defined in rfc4366 do NOT appear in rfc5246 (and were updated by rfc6066). On top of that, in order to implement TLS extensions for TLSv1.0 or TLSv1.1, rfc4366 is indispensible, because it describes the necessary changes to the TLSv1.0 & TLSv1.1 PDUs, information that would be cumbersome to extract from rfc5246 compared to simply using rfc4366.
"Obsoletes: 3268" is factually incorrect, because 3268 is the document needed to implement the AES ciphersuites in implementations of TLS _prior_ to TLSv1.2,
such as TLSv1.0(rfc2246) and TLSv1.1(rfc4346), i.e. to add support for AES ciphersuites to an existing implementation of TLSv1.0, one would use TLSv1.0(rfc2246) plus rfc3268, rather than TLSv1.0 plus some undefined fragments of rfc5246.
--VERIFIER NOTES--
If you're looking to implement TLS 1.1 or TLS 1.0 you should be looking in those earlier specifications not RFC 5246.
One RFC can be obsoleted by more than RFC.