On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson <m...@lowentropy.net> wrote:
> 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. > Yes, although 8773 actually is not super-clear about post-handshake, so that's actually something we should clarify there. > 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, [...] > I see what you are trying to do, but I think if we are to restrict this to resumption here it might leave the wrong impression. I think it would help to be more explicit here: Servers which are authenticating with a resumption PSK MUST NOT send the CertificateRequest message in the main handshake, [...], Servers which are authenticating with an external PSK MUST NOT send the CertificateRequest message either in the main handshake or in the post-handshake phase. Future specifications MAY provide an extension to permit this. This would be consistent with the erratum Chris proposed -Ekr > > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
