Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09

Nick Sullivan <nick@cloudflare.com> Tue, 19 November 2019 02:56 UTC

Return-Path: <nick@cloudflare.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 C13C612080F for <tls@ietfa.amsl.com>; Mon, 18 Nov 2019 18:56:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 IXa1GbQ_IIZU for <tls@ietfa.amsl.com>; Mon, 18 Nov 2019 18:56:33 -0800 (PST)
Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 0A7D612080E for <tls@ietf.org>; Mon, 18 Nov 2019 18:56:33 -0800 (PST)
Received: by mail-vk1-xa2f.google.com with SMTP id o2so4686136vkc.13 for <tls@ietf.org>; Mon, 18 Nov 2019 18:56:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LQv/yJUOs3pUDQmlgpAmiyMpmDQXtVVk0ML3PkFLzxk=; b=iUG9q4TtqyjaOWftVHZ/z6Ta4SfmejIIbTZB1eImCTTVKAlAy6MAgNSJy3JQuL42QY WvIeP/Q4iKsQKb/UOXpGKB6jHmnWjv087HWnsdorSESfqpY1h4JzuRdjpBsV9Z1TlhX2 RzRyE7BewVWEmV1WCAxx/7AjiNzXSoPrI1kD0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LQv/yJUOs3pUDQmlgpAmiyMpmDQXtVVk0ML3PkFLzxk=; b=sJCuYT11JctVnuPfUrZQGEo0sC2bm0BJouzlHicyi5Ue7n+HcSNDtjMmY+RSzEM8vj gUMLjFoF8VNLdbleO9FgoAMNk/4Cy5HW7ZGukQDtKkdxpfOFf+48PL2cAZKJGK/j/wTC RyYkLt44APvEV5IhbeYb3jj1fgr/IWk378QlHdQPHXVkZD4Qg2wWDDdaBNTnjT0nS0CB B/5+FDP5DgVPbkgjAzIEyDKH2KkboVODF2azihsXs9LkC/QA4PYyfbo8UhsUjp1cfbhv ydpev9nONa0cEBLrn0I1KG61ETnx9RpgfNF/lk0F81uGrIdgtJRngM8dHpG73ytpR/bW 5XEQ==
X-Gm-Message-State: APjAAAUKFccrNwdYfolouwnpEd6ZlKiyOB6n4X+ktDKzHDACz4jiSB/W 3E3wsCulAW/E59Rub1/dEGL2v5MmuRdq43Qwhh7c3A==
X-Google-Smtp-Source: APXvYqwBfDE5Jgmax36ij8KjskPbKiy2ovsGhceV1zkaCDugRDlu1TvGNcQq0BfRzVzzTedFWNw6fHZJ7hHFnSsMjoI=
X-Received: by 2002:a1f:2cd:: with SMTP id 196mr10263419vkc.23.1574132191837; Mon, 18 Nov 2019 18:56:31 -0800 (PST)
MIME-Version: 1.0
References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> <CAFDDyk_xvfDFK1_G3aqr9b5J6a-62=tjpdraXHGDpeiHdk10tA@mail.gmail.com> <CAFDDyk8sOw-G72KoJ76dS_etmO3zsJ58HuAkhAysFQPG2U-R0Q@mail.gmail.com> <D8E32D23-AE51-48BD-9B01-64F73DED0BFD@gmail.com> <CAFDDyk-s0jMnZy_mEAct15kwQG5cEZpyonDJxf+d9gQ6YBisGA@mail.gmail.com> <20191118225035.GS20609@akamai.com>
In-Reply-To: <20191118225035.GS20609@akamai.com>
From: Nick Sullivan <nick@cloudflare.com>
Date: Tue, 19 Nov 2019 10:56:14 +0800
Message-ID: <CAFDDyk86++0rn0KcrWixVGVc4wQ9G5vv+17Hx7ftvZuoAVs_9Q@mail.gmail.com>
To: Benjamin Kaduk <bkaduk@akamai.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, "<tls@ietf.org>" <tls@ietf.org>, draft-ietf-tls-exported-authenticator.all@ietf.org, ietf@ietf.org, secdir@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001ff5830597aa364c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sxI4xhTyzLgvj3oYQ1_enXPsI6w>
Subject: Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09
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, 19 Nov 2019 02:56:45 -0000

On Tue, Nov 19, 2019 at 6:50 AM Benjamin Kaduk <bkaduk@akamai.com>; wrote:

> On Sun, Nov 17, 2019 at 04:42:05PM +0800, Nick Sullivan wrote:
> > Hi Yaron,
> >
> > Thanks for reminding me about the codepoint issue. It's a sticky one.
> >
> > As far as I see it, there are three options:
> >
> > a) Change the document to UPDATE RFC 8446
> > This feels like a heavyweight option and may complicate things since it
> > will mean that SNI is allowed but undefined for CertificateVerify in the
> > TLS handshake.
> >
> > b) Ask for a new extension point for SNI sent in a client-generated
> > authenticator request.
> > This has the downside of not scaling to future client hello extensions
> that
> > could be useful in exported authenticator requests -- it forces the
> > definition of a new code point for each new extension.
> >
> > c) Explicitly state that the CertificateRequest-like construction in
> > client-generated exported authenticator requests is a new type of message
> > (analogous to a ClientHello) and clarify the rules about which extensions
> > can be used when it is client-generated (specifically, say that any
> > extension supported in CH is allowed)
> > This is my preferred solution.
>
> Just to check: this would be adding a new possible value for the "TLS 1.3"
> column at
> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1
> ?
>
Not necessarily. The text could be amended to say something like:
  "the allowed extensions for client-generated authenticator requests need
to have CH listed, and for server-generated authenticator requests need to
have CR listed"

The only current extension that supports CR, but not CH is oid_filters,
which is not relevant to client-initiated authenticator requests.


> Thanks,
>
> Ben
>
> > I'm interested to hear what the working group thinks, and I'll happily
> > present the options at IETF 106 if there's time.
> >
>