RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Verified (1)

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

Source of RFC: uta (app)

Errata ID: 4353

Status: Verified
Type: Editorial

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.

Status: Rejected (1)

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

Source of RFC: uta (app)

Errata ID: 4360

Status: Rejected
Type: Technical

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



Search RFCs
Advanced Search
×