Subject: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-03: (with COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Wed, 11 Dec 2019 09:16:51 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-tls-tls13-cert-with-extern-psk-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Just a small thing to double-check: I wonder if this sentence would actually
require an update to RFC8446:
   "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."
Or maybe it should be phrased differently, just:
"If the "tls_cert_with_extern_psk" extension is negotiated, certificate-based
authentication is allowed for both the client and the server." I guess it
depends on what exactly is said in RFC8446 (and I didn't went and tried to find
it).

And as a side note, it is usually recommended to provide the link to the
registry in the IANA section (to make life for IANA easier).

---

From: Russ Housley <[email-masked]>
Date: Wed, 11 Dec 2019 12:48:58 -0500

I do not believe that an update is needed or appropriate.  First, the presence of this extension is an indication that this behavior will be different.  Second, this is going to be an Experimental RFC, so it should not update a standards-track RFC.

> registry in the IANA section (to make life for IANA easier)

I will gladly add a reference to the registry:

https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

Russ

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 12 Dec 2019 22:44:53 -0800

> I do not believe that an update is needed or appropriate.  First, the presence of this extension is an indication that this behavior will be different.  Second, this is going to be an Experimental…

I agree; this is just an extension working as normal.  (Not that I haven't
asked the same question before for other documents....)

-Ben

---

From: "Mirja Kühlewind (IETF)" <[email-masked]>
Date: Fri, 13 Dec 2019 09:04:49 +0100

Okay that’s fine. It was just the wording of this one sentence that made me ask this question.

> Am 13.12.2019 um 07:45 schrieb Benjamin Kaduk <[email-masked]>:
>