RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Verified (5)

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

Note: This RFC has been updated by RFC 8996, RFC 9416

Source of RFC: IAB

Errata ID: 2142
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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"

Errata ID: 7610
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Pete Jorgensen
Date Reported: 2023-08-19
Verifier Name: Mirja Kühlewind
Date Verified: 2024-01-11

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.  In such a system, an attacker can
   initiate an association posing as the unauthenticated peer but cannot
   transmit or access data being sent on a legitimate connection.  This
   is an acceptable situation in contexts such as Web e-commerce where
   only the server needs to be authenticated (or the client is
   independently authenticated via some non-cryptographic mechanism such
   as a credit card number).

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.  In such a system, an attacker can
   initiate an association posing as the unauthenticated peer but cannot
   transmit or access data being sent on a legitimate connection.  This
   is an acceptable situation in contexts such as Web e-commerce where
   only the server needs to be authenticated (or the client is
   independently authenticated via some non-cryptographic mechanism such
   as a credit card number).

Notes:

2nd sentence fix "the the".

Status: Held for Document Update (1)

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

Note: This RFC has been updated by RFC 8996, RFC 9416

Source of RFC: IAB

Errata ID: 3562
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
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



Advanced Search