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

Benjamin Kaduk <kaduk@mit.edu> Fri, 13 December 2019 06:45 UTC

Return-Path: <kaduk@mit.edu>
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 5D8D912024E; Thu, 12 Dec 2019 22:45:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 O153Mu9gpGC2; Thu, 12 Dec 2019 22:45:04 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 785B81200F7; Thu, 12 Dec 2019 22:45:01 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBD6irAo029797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Dec 2019 01:44:56 -0500
Date: Thu, 12 Dec 2019 22:44:53 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Russ Housley <housley@vigilsec.com>
Cc: Mirja =?iso-8859-1?Q?K=FChlewind?= <ietf@kuehlewind.net>, 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>
Message-ID: <20191213064453.GF81833@kduck.mit.edu>
References: <157608461199.11437.2061730930042533586.idtracker@ietfa.amsl.com> <E5BA7D7B-353C-44BF-AA6E-0396554DE9CA@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E5BA7D7B-353C-44BF-AA6E-0396554DE9CA@vigilsec.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3iSd21G4CbbIssjGAn-XSf9wIuA>
Subject: Re: [TLS] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-tls-tls13-cert-with-extern-psk-03=3A_=28with_COMMENT?= =?iso-8859-1?q?=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: Fri, 13 Dec 2019 06:45:06 -0000

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
>