RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (2)

RFC 7525, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", May 2015

Note: This RFC has been obsoleted by RFC 9325

Note: This RFC has been updated by RFC 8996

Source of RFC: uta (sec)

Errata ID: 4353
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Xiaoyin Liu
Date Reported: 2015-05-04
Verifier Name: Barry Leiba
Date Verified: 2015-05-07

Section 7.2 says: 

[RFC7507]  Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
           Suite Value (SCSV) for Preventing Protocol Downgrade
           Attacks", RFC 7507, April 2015.

It should say:

[RFC7507]  Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
           Suite Value (SCSV) for Preventing Protocol Downgrade
           Attacks", RFC 7507, April 2015,
           <http://www.rfc-editor.org/info/rfc7507>.

Notes:

The original text lacks the link to the RFC7507 information page.

Errata ID: 5685
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thijs Alkemade
Date Reported: 2019-04-05
Verifier Name: RFC Editor
Date Verified: 2024-02-15

Section 7 says: 

   [TLS-XMPP] Saint-Andre, P. and a. alkemade, "Use of Transport Layer
              Security (TLS) in the Extensible Messaging and Presence
              Protocol (XMPP)", Work in Progress,
              draft-ietf-uta-xmpp-07, April 2015.

It should say:

   [TLS-XMPP] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer
              Security (TLS) in the Extensible Messaging and Presence
              Protocol (XMPP)", Work in Progress,
              draft-ietf-uta-xmpp-07, April 2015.

Notes:

Fixed my name.

Status: Rejected (1)

RFC 7525, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", May 2015

Note: This RFC has been obsoleted by RFC 9325

Note: This RFC has been updated by RFC 8996

Source of RFC: uta (sec)

Errata ID: 4360
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Rex
Date Reported: 2015-05-08
Rejected by: Barry Leiba
Date Rejected: 2015-05-28

Section 6.1 says: 

6.1. Host Name Validation

   Application authors should take note that some TLS implementations do
   not validate host names.  If the TLS implementation they are using
   does not validate host names, authors might need to write their own
   validation code or consider using a different TLS implementation.

It should say:

6.1. Host Name Validation

   Application authors should take note that the TLS protocol explicitly
   defers checking of names and attributes of end-entity certificates
   to applications, see last sentence of RFC5246 , Section 1 (TLSv1.2).

   Some TLS implementations may offer a convenience function to perform
   a server endpoint identification according to RFC 2818, Section 3
   (HTTP over TLS).  For TLS implementations without such a convenience
   function, and for applications with different server identification
   schemes, application implementors may have to write the necessary
   code themselves.

Notes:

TLSv1.0 (rfc2246), TLSv1.1 (rfc4346) and TLSv1.2 (rfc5246) are quite
clear in that the original text is misleading on the actual properties
provided by a TLS implementation itself:

https://tools.ietf.org/html/rfc5246#page-5

how to interpret the authentication certificates
exchanged are left to the judgment of the designers and implementors
of protocols that run on top of TLS.
--VERIFIER NOTES--
The text is not incorrect as it stands, and, while this suggested change would have been good input during document development, it's not an erratum.

Report New Errata



Advanced Search