RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (4)

RFC 3552, "Guidelines for Writing RFC Text on Security Considerations", July 2003

Source of RFC: IAB

Errata ID: 2142

Status: Verified
Type: Editorial

Reported By: Lev Novikov
Date Reported: 2010-04-08
Verifier Name: Danny McPherson
Date Verified: 2010-09-10

Section 4.5.2.2 says:

   Note that if the client has a certificate than SSL-based client
   authentication can be used.  To make this easier, SASL provides the
   EXTERNAL mechanism, whereby the SASL client can tell the server
   "examine the outer channel for my identity".  Obviously, this is not
   subject to the layering attacks described above.

It should say:

   Note that if the client has a certificate then SSL-based client
   authentication can be used.  To make this easier, SASL provides the
   EXTERNAL mechanism, whereby the SASL client can tell the server
   "examine the outer channel for my identity".  Obviously, this is not
   subject to the layering attacks described above.

Notes:

Changed "than" to "then".

Errata ID: 2248

Status: Verified
Type: Editorial

Reported By: Glen Zorn
Date Reported: 2010-05-07
Verifier Name: Danny McPherson
Date Verified: 2010-09-10

Section 4.5.1 says:

modifying with the kernel or installing new drivers.  

It should say:

modifying the kernel or installing new drivers.  

Notes:

Correct poor grammar.

Errata ID: 3828

Status: Verified
Type: Editorial

Reported By: Eliot Lear
Date Reported: 2013-12-09
Verifier Name: RFC Editor
Date Verified: 2014-09-03

Section 5 says:

Part of the purpose of the
Security Considerations section is to explain what attacks are out of
scope and what countermeasures can be applied to defend against them.
In

It should say:

Part of the purpose of the Security Considerations section
is to explain what attacks are in and out of scope and what
countermeasures can be applied to defend against them.

Notes:

Note dangling "In".

Not sure if this is exactly what the authors had in mind, and might suggest a more substantial change in a document update. For the moment I *think* this covers it.

Errata ID: 4563

Status: Verified
Type: Editorial

Reported By: Walter Dolce
Date Reported: 2015-12-13
Verifier Name: Andrew Sullivan
Date Verified: 2016-01-07

Section 4.2. says:

This problem exists with any negotiation approach, but 
generic frameworks exacerbate it by encouraging the application 
protocol author to just specify the framework rather than think hard 
about the appropriate underlying mechanisms, particularly since the 
mechanisms can very widely in the degree of security offered.

It should say:

This problem exists with any negotiation approach, but 
generic frameworks exacerbate it by encouraging the application 
protocol author to just specify the framework rather than think hard 
about the appropriate underlying mechanisms, particularly since the 
mechanisms can vary widely in the degree of security offered.

Notes:

At the end of the paragraph, I think "very" should be changed to "vary"

Status: Held for Document Update (1)

RFC 3552, "Guidelines for Writing RFC Text on Security Considerations", July 2003

Source of RFC: IAB

Errata ID: 3562

Status: Held for Document Update
Type: Editorial

Reported By: James Abley
Date Reported: 2013-03-22
Held for Document Update by: Russ Housley

Section 3.3.5 says:

Note that it is only necessary to authenticate one side of the 
transaction in order to prevent man-in-the-middle attacks.  In such a
situation the the peers can establish an association in which only
one peer is authenticated.

It should say:

Note that it is only necessary to authenticate one side of the 
transaction in order to prevent man-in-the-middle attacks.  In such a
situation the peers can establish an association in which only
one peer is authenticated.

Notes:

Remove repetition of "the"

Report New Errata



Search RFCs
Advanced Search
×