Re: [TLS] [Errata Held for Document Update] RFC8446 (6205)
Yeah, we talked about this one and came to a reasonable conclusion that was based on what I wrote at the time, but better because RFC 8773 exists. The added text: > In the absence of some other specification to the contrary, servers which are > authenticating with an external PSK MUST NOT send the CertificateRequest > message either in the main handshake or request post-handshake > authentication. [RFC8773] provides an extension to permit this, but has not > received the level of analysis as this specification. You could improve further, slightly, on an editorial basis: s/the level of analysis/the same level of analysis/ On Wed, Jan 17, 2024, at 13:12, Eric Rescorla wrote: > I believe that the current 8446-bis text addresses this. Martin? > > On Tue, Jan 16, 2024 at 4:59 PM RFC Errata System > wrote: >> The following errata report has been held for document update >> 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/eid6205 >> >> -- >> Status: Held for Document Update >> Type: Editorial >> >> Reported by: Martin Thomson >> Date Reported: 2020-06-04 >> Held by: Paul Wouters (IESG) >> >> Section: 4.3.2 >> >> Original Text >> - >>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). >> >> Corrected Text >> -- >>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. >> >> -- >> 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
Re: [TLS] [Errata Held for Document Update] RFC8446 (6205)
I believe that the current 8446-bis text addresses this. Martin? On Tue, Jan 16, 2024 at 4:59 PM RFC Errata System wrote: > The following errata report has been held for document update > 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/eid6205 > > -- > Status: Held for Document Update > Type: Editorial > > Reported by: Martin Thomson > Date Reported: 2020-06-04 > Held by: Paul Wouters (IESG) > > Section: 4.3.2 > > Original Text > - >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). > > Corrected Text > -- >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. > > -- > 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] [Errata Held for Document Update] RFC8446 (6205)
The following errata report has been held for document update 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/eid6205 -- Status: Held for Document Update Type: Editorial Reported by: Martin Thomson Date Reported: 2020-06-04 Held by: Paul Wouters (IESG) Section: 4.3.2 Original Text - 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). Corrected Text -- 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. -- 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
