RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 35 records.

Status: Verified (1)

RFC 8446, "The Transport Layer Security (TLS) Protocol Version 1.3", August 2018

Source of RFC: tls (sec)

Errata ID: 5976
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Rich Salz
Date Reported: 2020-02-04
Verifier Name: Benjamin Kaduk
Date Verified: 2020-03-07

Section 11 says:

   This document updates an entry in the TLS Certificate Types registry
   originally created in [RFC6091] and updated in [RFC8447].  IANA has
   updated the entry for value 1 to have the name "OpenPGP_RESERVED",
   "Recommended" value "N", and comment "Used in TLS versions prior
   to 1.3."

It should say:

   This document updates two entries in the TLS Certificate Types registry
   originally created in [RFC6091] and updated in [RFC8447].  IANA has
   updated the entry for value 1 to have the name "OpenPGP_RESERVED",
   "Recommended" value "N", and comment "Used in TLS versions prior
   to 1.3."  IANA has updated the entry for value 0 to have the name
   "X509", "Recommended" value "Y", and comment "Was X.509 before TLS 1.3".

Notes:

The protocol description language changed the spelling used for "X509", and the registry should be updated to match.

Status: Reported (34)

RFC 8446, "The Transport Layer Security (TLS) Protocol Version 1.3", August 2018

Source of RFC: tls (sec)

Errata ID: 5483
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Patrick Kelsey
Date Reported: 2018-08-28

Section 4.2.8.2 says:

For X25519 and X448, the contents of the public value are the byte
string inputs and outputs of the corresponding functions defined in
[RFC7748]: 32 bytes for X25519 and 56 bytes for X448.

It should say:

For X25519 and X448, the contents of the public value are the byte
string outputs of the corresponding functions defined in [RFC7748]: 32
bytes for X25519 and 56 bytes for X448.

Notes:

Per Section 7.4.2 of this RFC and Section 6 of RFC7748, the byte string inputs to the corresponding ECDH scalar multiplication function are the private key and the u-coordinate of the standard public base point, the former of which of course must not be transmitted and the latter of which is a known constant.

From another perspective, including the byte string inputs in the contents of the public value would contradict the resulting content sizes given at the end of the cited paragraph as well as the statement in Section 7.4.2 that the public key put into the KeyShareEntry is the output of ECDH scalar multiplication function.

Errata ID: 5682
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Richard Barnes
Date Reported: 2019-04-01

Section 4.3.2, B.3.2 says:

--- rfc8446.txt	2018-08-10 20:12:08.000000000 -0400
+++ rfc8446.erratum.txt	2019-04-01 15:44:54.000000000 -0400
@@ -3341,7 +3341,7 @@
 
       struct {
           opaque certificate_request_context<0..2^8-1>;
-          Extension extensions<2..2^16-1>;
+          Extension extensions<0..2^16-1>;
       } CertificateRequest;
 
 
@@ -7309,7 +7309,7 @@
 
       struct {
           opaque certificate_request_context<0..2^8-1>;
-          Extension extensions<2..2^16-1>;
+          Extension extensions<0..2^16-1>;
       } CertificateRequest;
 
 

It should say:

--- rfc8446.txt	2018-08-10 20:12:08.000000000 -0400
+++ rfc8446.erratum.txt	2019-04-01 15:44:54.000000000 -0400
@@ -3341,7 +3341,7 @@
 
       struct {
           opaque certificate_request_context<0..2^8-1>;
-          Extension extensions<2..2^16-1>;
+          Extension extensions<0..2^16-1>;
       } CertificateRequest;
 
 
@@ -7309,7 +7309,7 @@
 
       struct {
           opaque certificate_request_context<0..2^8-1>;
-          Extension extensions<2..2^16-1>;
+          Extension extensions<0..2^16-1>;
       } CertificateRequest;
 
 

Notes:

The length of this vector can never 2. It is either 0, if the vector is empty, or >=4, if the vector has at least one extension. Nothing elsewhere in the spec requires a non-zero number of extensions here, so this syntax should allow a zero-length vector.

Errata ID: 5868
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Hubert Kario
Date Reported: 2019-10-02

Section 4.2.3 says:

   ECDSA algorithms:  Indicates a signature algorithm using ECDSA
      [ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA]
      and FIPS 186-4 [DSS], and the corresponding hash algorithm as
      defined in [SHS].  The signature is represented as a DER-encoded
      [X690] ECDSA-Sig-Value structure.

It should say:

   ECDSA algorithms:  Indicates a signature algorithm using ECDSA
      [ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA]
      and FIPS 186-4 [DSS], and the corresponding hash algorithm as
      defined in [SHS].  The signature is represented as a DER-encoded
      [X690] ECDSA-Sig-Value structure as defined in [RFC4492].

Notes:

There is a possibility for confusion as the ECDSA-Sig-Value has two conflicting definitions in authoritative standards. TLS always used the following (see RFC4492):

ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}

but the publicly accessible SECG SEC1 v2.0 (https://www.secg.org/sec1-v2.pdf) defines it like this:

ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER,
a INTEGER OPTIONAL,
y CHOICE { b BOOLEAN, f FieldElement } OPTIONAL
}

I think using the RFC5480 in the Corrected Text would be cleaner than RFC4492, but the former is not an existing reference, so we would need to update section 12 also.

Errata ID: 5874
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Mr Laurie Perrin
Date Reported: 2019-10-12

Section 5.1 says:

...

   Application Data messages contain data that is opaque to TLS.
   Application Data messages are always protected.  Zero-length
   fragments of Application Data MAY be sent, as they are potentially
   useful as a traffic analysis countermeasure.  Application Data
   fragments MAY be split across multiple records or coalesced into a
   single record.

It should say:

...

   Application Data messages contain data that is opaque to TLS.
   Application Data messages are always protected.  Zero-length
   fragments of Application Data (i.e. those encapsulating an
   TLSInnerPlaintext record having a content field of length zero)
   MAY be sent, as they are potentially useful as a traffic analysis
   countermeasure. Application Data fragments MAY be split across
   multiple records or coalesced into a single record.

Notes:

In the interest of clarity, it may be prudent to specify the type of record for
which a fragment of length zero is being considered - it cannot be that of the
TLSCiphertext itself, for "Application Data messages are always protected,"
therefore I infer this relates to the TLSInnerPlaintext content field (of
length "TLSPlaintext.length") - i.e. to the TLSPlaintext fragment.

Note: This comment also applies to previous versions of the TLS specification,
in particular with the introduction of the respective text concerning zero-length
fragments in RFC 5246. In TLS 1.2, this would be the GenericXXCipher content
field of length "TLSCompressed.length" - i.e. to the TLSCompressed fragment.

Note: The implications of zero-length records must be considered with respect to
potential vectors for denial of service.

Errata ID: 6123
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-24

Section 2 says:

The handshake protocol allows peers to negotiate a protocol version, select cryptographic algorithms, optionally authenticate each other, and establish shared secret keying material.

Notes:

Only client authentication is optional (albeit, server authentication is implicit for PSK-only key exchange mode)

Errata ID: 6136
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-28

Section 4.1.4 says:

   Upon receipt of a HelloRetryRequest, the client MUST check the
   legacy_version, legacy_session_id_echo, cipher_suite, and     
   legacy_compression_method as specified in Section 4.1.3 

Notes:

Section 4.1.3 defines no checks for legacy_version nor legacy_compression_method

Errata ID: 6142
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-29

Section 4.6.1. says:

Clients MUST NOT cache tickets for longer than 7 days

It should say:

Clients MUST NOT use tickets for longer than 7 days

Notes:

"MUST NOT cache" is surely overly zealous and may unnecessarily result in non-compliant implementations

Errata ID: 6143
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-29

Section 4.2.7 says:

As of TLS 1.3, servers are permitted to send the "supported_groups"
extension to the client.

Notes:

It is unclear whether servers are permitted to send the "supported_groups" extension to
the client without solicitation, i.e., when the client does not first send the extension to the
server. Clarification would be useful.

Errata ID: 6145
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-29

Section 4.2.10. says:

When a PSK is used and early data is allowed for that PSK

Notes:

I couldn't find restrictions that forbid early data for a PSK. Explaining where such restrictions
could exist would be useful. E.g., PSKs might be associated with data that forbids early data.

Errata ID: 6146
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-29

Section 4.2.10. says:

The TLS version number

It should say:

The selected TLS version number

Errata ID: 6151
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-30

Section 4.4 says:

   | Post-     | ClientHello ... client  | client_application_traffic_ |
   | Handshake | Finished +              | secret_N                    |
   |           | CertificateRequest      |                             |

It should say:

   | Post-     | ClientHello ... client  | [sender]_application_traffic|
   | Handshake | Finished +              | _secret_N                   |
   |           | CertificateRequest      |                             |

Errata ID: 6152
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-05-01

Section 4 says:

Clients MUST check for ["supported_versions"] prior to
processing the rest of the ServerHello (although they will have to 
parse the ServerHello in order to read the extension). -- Section 4.2.1.

Upon receipt of a HelloRetryRequest, the client MUST check the
legacy_version, legacy_session_id_echo, cipher_suite, and
legacy_compression_method as specified in Section 4.1.3 and then
process the extensions, starting with determining the version using
"supported_versions". -- Section 4.1.4

Upon receiving a message with type server_hello, implementations MUST
first examine the Random value... -- Section 4.1.3.

Notes:

These requirements are seemingly conflicting. I suspect checking for "supported_versions" must
come first, since that may influence subsequent steps, e.g., checking legacy_compression_method
and the Random value. It doesn't seem to matter whether legacy_version, legacy_session_id_echo,
cipher_suite, and legacy_compression_method are checked before the Random value, so it doesn't
seem to matter which check is second and which is third. (Noting, as per one of my earlier reports,
dated 28 Apr, Section 4.1.3 defines no checks for legacy_version nor legacy_compression_method.
Perhaps the latter should be checked to be zero, aborting with alert illegal_parameter if it isn't, as per
Section 4.1.2.)

Errata ID: 6401
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Eric Covener
Date Reported: 2021-01-20

Section 4.6.2 says:

When the client has sent the "post_handshake_auth" extension (see
Section 4.2.6), a server MAY request client authentication at any
time after the handshake has completed by sending a
CertificateRequest message.  

It should say:

When the client has sent the "post_handshake_auth" extension (see
Section 4.2.6), a server MAY request client authentication during the 
main handshake and/or at any time after the handshake has completed by 
sending a CertificateRequest message.  


Notes:

4.6.2 is ambiguous as to whether it forbids "main handshake" (mid-handshake) client
authentication when the client has sent the "post_handshake_auth" extension. I think
the language would be stronger if it were really forbidden, and openssl s_server permits
this behavior and rfc8740 implies it as well.

The "main handshake" language is adopted from 4.3.2 but "main" could be dropped as
"handshake" is not ambiguous in 1.3 due to no renegotiation.

Errata ID: 5717
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Daniel Migault
Date Reported: 2019-05-03

Section 2.2. says:


 Figure 3 shows a pair of handshakes in which the first handshake
   establishes a PSK and the second handshake uses it:
 
          Client                                               Server
 
   Initial Handshake:
          ClientHello
          + key_share               -------->
                                                          ServerHello
                                                          + key_share
                                                {EncryptedExtensions}
                                                {CertificateRequest*}
                                                       {Certificate*}
                                                 {CertificateVerify*}
                                                           {Finished}
                                    <--------     [Application Data*]
          {Certificate*}
          {CertificateVerify*}
          {Finished}                -------->
                                    <--------      [NewSessionTicket]
          [Application Data]        <------->      [Application Data]
 
 
   Subsequent Handshake:
          ClientHello
          + key_share*
          + pre_shared_key          -------->
                                                          ServerHello
                                                     + pre_shared_key
                                                         + key_share*
                                                {EncryptedExtensions}
                                                           {Finished}
                                    <--------     [Application Data*]
          {Finished}                -------->
          [Application Data]        <------->      [Application Data]
 
               Figure 3: Message Flow for Resumption and PSK

It should say:


 Figure 3 shows a pair of handshakes in which the first handshake
   establishes a PSK and the second handshake uses it:
 
          Client                                               Server
 
   Initial Handshake:
          ClientHello
          + key_share               -------->
                                                          ServerHello
                                                          + key_share
                                                {EncryptedExtensions}
                                                {CertificateRequest*}
                                                       {Certificate*}
                                                 {CertificateVerify*}
                                                           {Finished}
                                    <--------     [Application Data*]
          {Certificate*}
          {CertificateVerify*}
          {Finished}                -------->
                                    <--------      [NewSessionTicket]
          [Application Data]        <------->      [Application Data]
 
 
   Subsequent Handshake:
          ClientHello
          + key_share*
          + psk_key_exchange_modes        
          + pre_shared_key          -------->

                                                          ServerHello
                                                     + pre_shared_key
                                                         + key_share*
                                                {EncryptedExtensions}
                                                           {Finished}
                                    <--------     [Application Data*]
          {Finished}                -------->
          [Application Data]        <------->      [Application Data]
 
               Figure 3: Message Flow for Resumption and PSK

Notes:

The pre_shared_key requires the pre_share_key extension. As mentioned by Martin Thompson figures do not necessarily guarantee all extensions to be mentioned. However in this case, that would be clarifying to have both extensions mentioned on the figure.

Errata ID: 6120
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-24

Section 1 says:

the underlying transport is a reliable, in-order data stream


It should say:

the underlying transport layer is a reliable, in-order stream delivery service

or

the underlying transport protocol is a reliable, in-order stream delivery service

or similar

Notes:

Similar elsewhere

Errata ID: 6121
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-24

Section 1 says:

cryptographic modes

It should say:

cryptographic algorithms

Errata ID: 6122
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-24

Section 1.2 says:

The key derivation functions have been redesigned.

It should say:

The key derivation function has been redesigned.

Errata ID: 6124
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-24

Section 2 says:

   In the Key Exchange phase, the client sends the ClientHello                  
   (Section 4.1.2) message, which contains a random nonce                       
   (ClientHello.random); its offered protocol versions; a list of               
   symmetric cipher/HKDF hash pairs; either a set of Diffie-Hellman key         
   shares (in the "key_share" (Section 4.2.8) extension), a set of              
   pre-shared key labels (in the "pre_shared_key" (Section 4.2.11)              
   extension), or both; and potentially additional extensions.   

It should say:

   In the Key Exchange phase, the client sends the ClientHello                  
   (Section 4.1.2) message, which contains a random nonce                       
   (ClientHello.random); its offered protocol versions; a list of               
   symmetric cipher/Hash algorithm pairs; either a set of Diffie-Hellman key         
   shares (in the "key_share" (Section 4.2.8) extension), a set of              
   pre-shared key labels (in the "pre_shared_key" (Section 4.2.11)              
   extension), or both; and potentially additional extensions.   

or

   In the Key Exchange phase, the client sends the ClientHello                  
   (Section 4.1.2) message, which contains a random nonce                       
   (ClientHello.random); its offered protocol versions; a list of               
   symmetric cipher/Hash algorithm (to be used with HKDF) pairs; either a set of Diffie-Hellman key         
   shares (in the "key_share" (Section 4.2.8) extension), a set of              
   pre-shared key labels (in the "pre_shared_key" (Section 4.2.11)              
   extension), or both; and potentially additional extensions.   

Errata ID: 6125
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-24

Throughout the document, when it says:

PSKs are referred to as out-of-band and external

It should say:

Referring to PSKs as either out-of-band xor external would help at least one reader

Errata ID: 6126
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-24

Section 4.1.1 says:

Note that if the PSK can be used without (EC)DHE, then
non-overlap in the "supported_groups" parameters need not be fatal, 
as it is in the non-PSK case discussed in the previous paragraph.

It should say:

Note that if the PSK can be used without (EC)DHE, then
non-overlap in the "supported_groups" parameters need not be fatal, 
as it is in the non-PSK case discussed in the previous paragraph, 
because PSK-only key exchange mode does not need supported_groups.

Notes:

If "the PSK can be used without (EC)DHE", then PSK-only key exchange mode can be used, which doesn't require supported_groups. This is perhaps worthy of explanation.

Errata ID: 6127
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-24

Section 4.1.2. says:

If a "key_share" extension was supplied in the HelloRetryRequest,
replacing the list of shares with a list containing a single
KeyShareEntry from the indicated group.

It should say:

If a "key_share" extension was supplied in the HelloRetryRequest,
replacing the list of shares with a list containing a single
KeyShareEntry from the indicated group. Note: A "key_share" 
extension may not be supplied in a HelloRetryRequest message 
when a server receives  an "early_data" (Section 4.2.10).

Errata ID: 6128
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-24

Throughout the document, when it says:

terminate and abort are used interchangeable, but this isn't explained until after such use.

In Section 6.2, we have: In the rest of this specification, when the phrases "terminate the connection" and "abort the handshake" are used without a specific alert it means that the implementation SHOULD send the alert indicated by the
descriptions below.  

It should say:

Perhaps explain terminology earlier. At the very least, in Section 6.2, open the above sentence with "Throughout this specification"


Errata ID: 6135
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-28

Section Global says:

list, series, set, and vector are seemingly used as synonyms. 

It should say:

Using list, series, set, xor vector would help at least one reader. 

Notes:

Additionally, consistent usage is desirable, e.g., page 31 uses "A list of extensions" whereas "A set of
extensions" is used on page 60. Elsewhere inconsistently usage causes confusion, e.g.,
Page 48:

client_shares: A list of offered KeyShareEntry values in descending
order of client preference.

This vector MAY be empty if the client is requesting a

(Replace "vector" with "list", or vice versa.)

Errata ID: 6137
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-28

Section 4.2.10 says:

symmetric cipher suite

It should say:

cipher suite

Errata ID: 6138
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-28

Section 4.2.10 says:

   For externally              
   provisioned PSKs, the associated values are those provisioned along 
   with the key.  For PSKs established via a NewSessionTicket message, 
   the associated values are those which were negotiated in the        
   connection which established the PSK.  

   ...

   For externally established             
   PSKs, the associated values are those provisioned along with the key.
   For PSKs established via a NewSessionTicket message, the associated  
   values are those negotiated in the connection during which the ticket
   was established.                                                     

It should say:

   For externally              
   provisioned PSKs, the associated values are those provisioned along 
   with the key.  For PSKs established via a NewSessionTicket message, 
   the associated values are those which were negotiated in the        
   connection which established the PSK.  

Notes:

Drop largely verbatim duplicated text

Errata ID: 6139
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-29

Section 4.4.2.2. says:

As servers MAY require the presence of the "server_name" extension, clients
SHOULD send this extension, when applicable.

It should say:

As servers MAY require the presence of the "server_name" extension, client
SHOULD send this extension.

Notes:

Since it is unclear when it is applicable for a server to send the extension, dropping "when applicable"
seems appropriate. Alternatively, giving some extra guidance would be useful.

Errata ID: 6140
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-29

Section 4.4.2.2. says:

This fallback chain SHOULD NOT use the deprecated SHA-1 hash
algorithm in general, but MAY do so if the client's advertisement
permits it, and MUST NOT do so otherwise.

It should say:

This fullback chain MUST NOT use the deprecated SHA-1 hash,
except if advertised by the client, in which case it MAY.

Notes:

The original text is difficult to read, eliminating the unnecessary "SHOULD NOT" seems to make it
easier.

Errata ID: 6141
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-29

Section 4.4.3 says:

   -  The context string

It should say:

   -  The context string (defined below)

Errata ID: 6144
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-29

Section 4.2.8. says:

Upon receipt of this extension in a HelloRetryRequest, the client
MUST verify that...the selected_group field does not
correspond to a group which was provided in the "key_share" extension
in the original ClientHello.

It should say:

Upon receipt of this extension in a HelloRetryRequest, the client
MUST verify that...a key share was not offered (in the "key_share" 
extension in the original ClientHello) for the group in the 
selected_group field.

Notes:

The original text requires knowledge of the "key_share" extension and is rather hard to read,
the proposed text should be easier to understand.

Errata ID: 6147
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-29

Section 4.2.10. says:

In order to accept early data, the server MUST have accepted a PSK
cipher suite....In addition, it MUST verify that the
following values are the same as those associated with the
selected PSK:

...

-  The selected cipher suite

Notes:

Accepting the "PSK cipher suite" surely implies the PSK is associated with the cipher suite, hence,
"The selected cipher suite" can be dropped.

Errata ID: 6148
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-29

Section 4.2.10 says:

The selected ALPN [RFC7301] protocol, if any

It should say:

The selected ALPN [RFC7301] protocol, if extension application_layer_protocol_negotiation is present

Errata ID: 6150
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ben Smyth
Date Reported: 2020-04-29

Throughout the document, when it says:

Note that certificate-based client authentication is not available 
in PSK handshake flows (including 0-RTT). 

It should say:

Note that certificate-based client authentication is not available 
in PSK handshake flows (including 0-RTT), post-handshake 
certificate-based client authentication is possible.

Errata ID: 6204
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Chris Wood
Date Reported: 2020-06-03

Section E.1 says:

Implementations MUST NOT combine external PSKs with certificate-based authentication of either the client or the server unless negotiated by some extension.

It should say:

Implementations MUST NOT combine external PSKs with certificate-based authentication of either client or the server. Future specifications MAY provide an extension to permit this. 

Notes:

The existing text can be misread as permitting this combination upon negotiation of the "post_handshake_auth" extension, which would be incorrect. [1] describes an attack that can occur based on this misinterpretation. The proposed text aims to make clear that a *new* extension is required for this combination.

[1] https://link.springer.com/article/10.1007%2Fs11416-020-00352-0

Errata ID: 6205
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Martin Thomson
Date Reported: 2020-06-04

Section 4.3.2 says:

   Servers which are authenticating with a PSK MUST NOT send the
   CertificateRequest message in the main handshake, though they MAY
   send it in post-handshake authentication (see Section 4.6.2) provided
   that the client has sent the "post_handshake_auth" extension (see
   Section 4.2.6).

It should say:

   Servers which are authenticating with a resumption PSK MUST NOT send the
   CertificateRequest message in the main handshake, though they MAY
   send it in post-handshake authentication (see Section 4.6.2) provided
   that the client has sent the "post_handshake_auth" extension (see
   Section 4.2.6).  Servers which are authenticating with an external PSK
   MUST NOT send the CertificateRequest message either in the main handshake
   or request post-handshake authentication. Future specifications MAY
   provide an extension to permit this. 

Notes:

The lack of qualification on "authenticating with a PSK" implies that the statement applies equally to both external and resumption PSKs. However, there are two conditions being governed: whether a certificate can be requested during the handshake, and whether a certificate can be requested post-handshake. The latter of these requires different rules depending on the type of PSK.

We know from the analysis of resumption (see https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/) that combining a PSK handshake of either type with a client certificate is not safe. Thus, the prohibition on CertificateRequest during the handshake applies equally to both resumption and external PSKs.

For post-handshake, Appendix E.1 already discusses the risks of combining PSKs with certificates, citing the same analysis as above.

[...] It is unsafe to use certificate-based client
authentication when the client might potentially share the same
PSK/key-id pair with two different endpoints.

For this reason an external PSK is not safe to use with post-handshake authentication. A resumption PSK does not have this property, so the same prohibition doesn't apply.

Splitting the requirements as proposed makes this split clearer.

Report New Errata