Re: [TLS] Secdir telechat review of draft-ietf-tls-exported-authenticator-14

Benjamin Kaduk <kaduk@mit.edu> Tue, 06 April 2021 18:43 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 BD1843A2BEE; Tue, 6 Apr 2021 11:43:29 -0700 (PDT)
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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 TIEXeLiH4FQD; Tue, 6 Apr 2021 11:43:26 -0700 (PDT)
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 ADAF93A2BE8; Tue, 6 Apr 2021 11:43:25 -0700 (PDT)
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 136IhHJD019301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 6 Apr 2021 14:43:22 -0400
Date: Tue, 6 Apr 2021 11:43:17 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: secdir@ietf.org, draft-ietf-tls-exported-authenticator.all@ietf.org, last-call@ietf.org, tls@ietf.org
Message-ID: <20210406184317.GU79563@kduck.mit.edu>
References: <161737953853.16107.13360840429966992303@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <161737953853.16107.13360840429966992303@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/orx2EY6QdqHNTaVt-mFbZ6_nGaM>
Subject: Re: [TLS] Secdir telechat review of draft-ietf-tls-exported-authenticator-14
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: Tue, 06 Apr 2021 18:43:30 -0000

Hi Yaron,

Thanks for the (multiple!) reviews.

My understanding is that the intention is not to allow "server_name" in all
CertificateRequests but only specifically in the ClientCertificateRequest
case.  I think it can be helpful to notate that with a "CR" in the "TLS
1.3" column of the registry but we would need some further clarification as
to what that notation actually means.  I left some suggestions for how to
do that in my ballot position, but to summarize: a "comment" column in the
registry would be great for this, and failing that a note in the IANA
Considerations of this document to clarify what is and is not being
registered would probably work as well.

Thanks again for highlighting this point,

Ben

On Fri, Apr 02, 2021 at 09:05:38AM -0700, Yaron Sheffer via Datatracker wrote:
> Reviewer: Yaron Sheffer
> Review result: Has Issues
> 
> After a bit of back and forth over my *two* previous SecDir requests, I'm
> afraid that my original comment has not yet been fully addressed. The IANA
> considerations section (Sec. 8.1) adds server_name as a possible extension for
> CertificateRequest. This would be a non-backward compatible change to TLS.
> 
> IMO what we needed to do is both to clarify the allowed extensions for what
> Nick called "the CR-like structure" (almost done in Sec. 4, though the last
> sentence should by changed to include CertificateRequest) and undo the change
> to the TLS ExtensionType registry (not done, would require to remove Sec. 8.1).
> 
> * Nit: this sentence is repeated almost verbatim in Sec. 4 and Sec. 5, and in
> both cases is mangled.
> 
> Old:
> 
> The application layer protocol used to send the authenticator request SHOULD
> use a secure with equivalent security to TLS, such as QUIC [QUIC-TLS], as its
> as its underlying transport to keep the request confidential.
> 
> New:
> 
> The application layer protocol used to send the authenticator request SHOULD
> use a secure *channel* with equivalent security to TLS, such as QUIC
> [QUIC-TLS], as its ~~as its~~ underlying transport to keep the request
> confidential.
> 
>