Re: [TLS] [Errata Held for Document Update] RFC8446 (6205)

[Martin Thomson <[e-mail]>]

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 
> <[e-mail]> 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 <[e-mail]>
>> 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