Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-03: (with COMMENT)
"Mirja Kühlewind (IETF)" <ietf@kuehlewind.net> Fri, 13 December 2019 08:14 UTC
Return-Path: <ietf@kuehlewind.net>
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 577571200C5; Fri, 13 Dec 2019 00:14:58 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 brma-6uFYKm3; Fri, 13 Dec 2019 00:14:56 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12A071200EF; Fri, 13 Dec 2019 00:14:56 -0800 (PST)
Received: from [129.192.10.3] (helo=[10.149.0.130]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ifg66-000267-L6; Fri, 13 Dec 2019 09:14:50 +0100
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: "\"Mirja Kühlewind (IETF)\"" <ietf@kuehlewind.net>
Mime-Version: 1.0 (1.0)
Date: Fri, 13 Dec 2019 09:04:49 +0100
Message-Id: <9F9CE876-B6EE-4229-B2E6-C43C8C229210@kuehlewind.net>
References: <20191213064453.GF81833@kduck.mit.edu>
Cc: Russ Housley <housley@vigilsec.com>, IETF TLS <tls@ietf.org>, Joe Salowey <joe@salowey.net>, IESG <iesg@ietf.org>, draft-ietf-tls-tls13-cert-with-extern-psk@ietf.org, TLS Chairs <tls-chairs@ietf.org>
In-Reply-To: <20191213064453.GF81833@kduck.mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: iPhone Mail (17B111)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1576224896;6befbe05;
X-HE-SMSGID: 1ifg66-000267-L6
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-FQZgMO4MCH0NkIXmBq-8_m9Tus>
Subject: Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-03: (with COMMENT)
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: Fri, 13 Dec 2019 08:14:58 -0000
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 <kaduk@mit.edu>: > > On Wed, Dec 11, 2019 at 12:48:58PM -0500, Russ Housley wrote: >> 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. > > I agree; this is just an extension working as normal. (Not that I haven't > asked the same question before for other documents....) > > -Ben > >>> 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 >> >
- [TLS] Mirja Kühlewind's No Objection on draft-iet… Mirja Kühlewind via Datatracker
- Re: [TLS] Mirja Kühlewind's No Objection on draft… Russ Housley
- Re: [TLS] Mirja Kühlewind's No Objection on draft… Benjamin Kaduk
- Re: [TLS] Mirja Kühlewind's No Objection on draft… Mirja Kühlewind (IETF)