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

Russ Housley <housley@vigilsec.com> Wed, 11 December 2019 17:58 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417D71200E5 for <tls@ietfa.amsl.com>; Wed, 11 Dec 2019 09:58:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7lpPZmxpfje for <tls@ietfa.amsl.com>; Wed, 11 Dec 2019 09:58:38 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E12120088 for <tls@ietf.org>; Wed, 11 Dec 2019 09:58:38 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2C46A300B30 for <tls@ietf.org>; Wed, 11 Dec 2019 12:49:00 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZdpWVAliYuG8 for <tls@ietf.org>; Wed, 11 Dec 2019 12:48:58 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id DDB4C3005DB; Wed, 11 Dec 2019 12:48:57 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <157608461199.11437.2061730930042533586.idtracker@ietfa.amsl.com>
Date: Wed, 11 Dec 2019 12:48:58 -0500
Cc: IESG <iesg@ietf.org>, draft-ietf-tls-tls13-cert-with-extern-psk@ietf.org, Joe Salowey <joe@salowey.net>, TLS Chairs <tls-chairs@ietf.org>, IETF TLS <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E5BA7D7B-353C-44BF-AA6E-0396554DE9CA@vigilsec.com>
References: <157608461199.11437.2061730930042533586.idtracker@ietfa.amsl.com>
To: =?utf-8?Q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dnT-BuFR_CxzZbUK4JEvem9qeNI>
Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-tls13-cert-with-extern-psk-03=3A_=28with_COMMENT=29?=
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2019 17:58:41 -0000

Mirja:

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

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.

> 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)

I will gladly add a reference to the registry:

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

Russ