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

Yaron Sheffer <yaronf.ietf@gmail.com> Tue, 06 April 2021 21:10 UTC

Return-Path: <yaronf.ietf@gmail.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 DF2F23A3109; Tue, 6 Apr 2021 14:10:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.598
X-Spam-Level:
X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 1gzmJnWS94jR; Tue, 6 Apr 2021 14:10:03 -0700 (PDT)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 E61CF3A3108; Tue, 6 Apr 2021 14:10:02 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id j18so15632870wra.2; Tue, 06 Apr 2021 14:10:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=CKgKjOjVgGtLgzHM3z6BmIWM4jokAwAGHu+3f59QOQs=; b=deFMsZc4xcsUYjhHA4Zq18AFaSndH8JoE7dwy4gXGdNthO5F7qxjfIAmK2RZhUdYIr pBIg5KH/RweJRJdatjHFD26b/iacoKSAEYll+bpfBIrn61R0hNtuy7LbqIwtu01iX3HE +BfZkAS0EI8YpCAi+40sN8UpEEVQM3yPcIcpBOhxSFV/CejdIX7EMC5PwR++TOlTOJHH pJE7l04PPXnmNgfDitysETceqezRg6DdfhhrOAMxdyAJsJPNF7P58zoJSDLigFdo6WRf 8ocrKh500KL7pwtxUJC7n/MRNXfO7Jjs2IN8ev9CGl51gBxV8Z1MNLIkaw15tJ4CI1De 3oww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=CKgKjOjVgGtLgzHM3z6BmIWM4jokAwAGHu+3f59QOQs=; b=hlk+gk39RglppiuoYIaaMzz2SqLRU6WectjMtQQkdN3kkEri+rhPMXQ7bKywwmCJiY yEBXYy/ydIj0Odrw+IiJkbflmNZtOvkflVncmycmtcU/hjdFYQhAe4Mnzrhpkh/bA+Fr 5pXa1Ls4TJCzooKEXBhL2isqAqNyNoOrMPpKWKXN/H09+6bWIyMYUkMe8NdKYeXqq2ml 1uLsiyVzKFYnpfWwg/0qkwhvOf5uVHKCELA74B5/Ig+VpugZ/8O4r9aEdbO4iEQV6FYt meoq8+auQN5DMJMgw24yntEk5dlC6XqrnNBSuGUhPAJdEkVGjpprhad6Kx2njSx4hIwO x3JQ==
X-Gm-Message-State: AOAM533hLWfv0lAN/RPYP6TnVmczwMo1PNr2ZzZVzR5o/qlpzEje/o32 huC32XjvmZB7aO5LfmO4l1jgmLA3+D/0Zw==
X-Google-Smtp-Source: ABdhPJwxV8oPonnotY1DLF0SY4VfDEWUpxRJt0V8IqwqX8DZHkmiz5LwVuge/C54994KpyMksDKPmg==
X-Received: by 2002:adf:f742:: with SMTP id z2mr211098wrp.130.1617743395949; Tue, 06 Apr 2021 14:09:55 -0700 (PDT)
Received: from [192.168.68.107] (bzq-79-182-26-241.red.bezeqint.net. [79.182.26.241]) by smtp.gmail.com with ESMTPSA id b15sm34128498wrx.73.2021.04.06.14.09.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Apr 2021 14:09:55 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.47.21031401
Date: Wed, 07 Apr 2021 00:09:54 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: <secdir@ietf.org>, <draft-ietf-tls-exported-authenticator.all@ietf.org>, <last-call@ietf.org>, <tls@ietf.org>
Message-ID: <08710817-AA38-49F4-A115-78C9D4D5F448@gmail.com>
Thread-Topic: Secdir telechat review of draft-ietf-tls-exported-authenticator-14
References: <161737953853.16107.13360840429966992303@ietfa.amsl.com> <20210406184317.GU79563@kduck.mit.edu>
In-Reply-To: <20210406184317.GU79563@kduck.mit.edu>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/f5WcbnAKbPe9eDCMLkL4FSv6MPs>
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 21:10:05 -0000

I fully agree. Thank you Ben!

On 4/6/21, 21:43, "Benjamin Kaduk" <kaduk@mit.edu> wrote:

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