I think that this is a useful erratum and it should be approved/HFDU. The extension to which this text alludes is RFC 8773, not post_handshake_auth.
There is one other piece to this that is very confusing, and less clear. "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)." The motivation is the attack that Sam Scott et. al. found in their analysis of resumption: https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/ However, this statement is unclear on whether it applies to external, resumption, or both types of PSK, but without qualification as it is you might be forgiven for thinking that it is both. However, the document already says: "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." So I think that the right interpretation is that this statement applies to "a resumption PSK" only. If people agree with this interpretation, then I will file another erratum of the form: OLD: Servers which are authenticating with a PSK MUST NOT send the CertificateRequest message in the main handshake, [...] NEW: Servers which are authenticating with a resumption PSK MUST NOT send the CertificateRequest message in the main handshake, [...] On Thu, Jun 4, 2020, at 10:00, RFC Errata System wrote: > The following errata report has been submitted for RFC8446, > "The Transport Layer Security (TLS) Protocol Version 1.3". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6204 > > -------------------------------------- > Type: Editorial > Reported by: Chris Wood <c...@heapingbits.net> > > Section: E.1 > > Original Text > ------------- > Implementations MUST NOT combine external PSKs with certificate-based > authentication of either the client or the server unless negotiated by > some extension. > > Corrected Text > -------------- > 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 > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8446 (draft-ietf-tls-tls13-28) > -------------------------------------- > Title : The Transport Layer Security (TLS) Protocol Version 1.3 > Publication Date : August 2018 > Author(s) : E. Rescorla > Category : PROPOSED STANDARD > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
