Subject: [TLS] [Editorial Errata Reported] RFC8446 (6204)

From: RFC Errata System <[email-masked]>
Date: Wed, 3 Jun 2020 17:00:11 -0700 (PDT)

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 <[email-masked]>

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

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 04 Jun 2020 11:06:42 +1000

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:
> 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. 
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 Jun 2020 18:44:43 -0700

On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson <[email-masked]> 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.

>  "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.
>
> "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."-
>
> 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

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 04 Jun 2020 11:47:38 +1000

On Thu, Jun 4, 2020, at 11:44, Eric Rescorla wrote:
> Servers which are authenticating with a resumption PSK MUST NOT send 
> the CertificateRequest message in the main handshake, [...],

That sounds great.  I've a tiny tweak, but I will open an erratum with that suggestion.

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 03 Jun 2020 18:58:04 -0700

> That sounds great.  I've a tiny tweak, but I will open an erratum with 

That works for me, too.

Thanks,
Chris

---

From: Russ Housley <[email-masked]>
Date: Thu, 4 Jun 2020 11:46:35 -0400

Eric:

> On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> Yes, although 8773 actually is not super-clear about post-handshake, so that's actually something we should clarify there.

RFC 8773 is not intended for post handshake.  So, I never thought about that.  What is the use case you are considering?

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 4 Jun 2020 11:47:39 -0400

> Servers which are authenticating with a resumption PSK MUST NOT send the CertificateRequest message in the main handshake, [...]

Works for me too.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 Jun 2020 09:11:25 -0700

On Thu, Jun 4, 2020 at 8:46 AM Russ Housley <[email-masked]> 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.
>>
>
> RFC 8773 is not intended for post handshake.  So, I never thought about
> that.  What is the use case you are considering?
>

I don't have one. I'm just trying to make sure things are clear. perhaps an
erratum on 8773 to make ultra clear?

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Thu, 4 Jun 2020 12:24:41 -0400

Eric:

> I don't have one. I'm just trying to make sure things are clear. perhaps an erratum on 8773 to make ultra clear?

I do not find it unclear.  What do you have in mind?

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 Jun 2020 09:37:17 -0700

On Thu, Jun 4, 2020 at 9:24 AM Russ Housley <[email-masked]> wrote:

> I do not find it unclear.
>

I am looking at 5.2 which seems like it could be more precise.

> What do you have in mind?
>

Changing:
   TLS 1.3 does not permit the server to send a CertificateRequest
   message when a PSK is being used. This restriction is removed when
   the "tls_cert_with_extern_psk" extension is negotiated, allowing
   certificate-based authentication for both the client and the
   server. To: TLS 1.3 does not permit the server to send a
   CertificateRequest message when a PSK is being used. This restriction
   is removed when the "tls_cert_with_extern_psk" extension is
   negotiated, allowing certificate-based authentication for both the
   client and the server.

To:
   TLS 1.3 does not permit the server to send a CertificateRequest
   message when a PSK is being used. This restriction is removed when
   the "tls_cert_with_extern_psk" extension is negotiated, allowing
   certificate-based authentication for both the client and the
   server. To: TLS 1.3 does not permit the server to send a
   CertificateRequest message when a PSK is being used. This
   restriction is removed for the main handshake when the
   "tls_cert_with_extern_psk" extension is negotiated, allowing
   certificate-based authentication for both the client and the
   server. This extension has no impact on external PSK usage
   with post-handshake authentication, which is prohibited by
   TLS 1.3.

-Ekr

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 4 Jun 2020 13:54:51 -0400

> On Jun 4, 2020, at 12:37 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Thu, Jun 4, 2020 at 9:24 AM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> Eric:
> 

This works for me.  I wonder if "initial handshake" would be better than "main handshake"

Russ

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 09 Jun 2020 10:55:40 +1000

I see four copies of nearly the same text here, I just want to confirm that it is this last one that we are talking about:

> TLS 1.3 does not permit the server to send a CertificateRequest message when a PSK is being used. This restriction is removed for the main handshake when the "tls_cert_with_extern_psk" extension is negotiated, allowing certificate-based authentication for both the client and the server. This extension has no impact on external PSK usage with post-handshake authentication, which is prohibited by TLS 1.3.

> This works for me. I wonder if "initial handshake" would be better than 

"initial" or "main" both add confusion here, I would strike the qualification.  In TLS, there is only one handshake.

If you want to talk about use of a resumption PSK in this context, then maybe add another sentence that highlights the fact that a resumption PSK that is created from a connection that uses "tls_cert_with_extern_psk" can be used, but the resulting handshake cannot involve a CertificateRequest, though a post-handshake CertificateRequest is permitted.