Re: [secdir] [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: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAC21208DD for <secdir@ietfa.amsl.com>; Mon, 18 Nov 2019 18:56:37 -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=ham 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 IitJ94-tmeQ3 for <secdir@ietfa.amsl.com>; Mon, 18 Nov 2019 18:56:33 -0800 (PST)
Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 07ECC120801 for <secdir@ietf.org>; Mon, 18 Nov 2019 18:56:33 -0800 (PST)
Received: by mail-vk1-xa36.google.com with SMTP id p78so3525333vkp.8 for <secdir@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=byMr4az3gJ5UnZxtYoJB8d+wwtdAqQ97+lsr7xXOFg4DgWyfS6r2QBn4IpzkZoKXu2 JsiPZu8/Tw03fvJ4rfKEWRnIsxuBU2Te1pcAE0yw9wqmobTsr8VqpqSSapovBnYZJneV PcFWuda2s9muLSOB4mVDK8/O+/+XeazG5RwBth+IzNqtUEbOf6pKUGmsxm9QojRPnm7H jkFK5HcApBnH1m6Dz1u8eOHEkPnvGQD71w4v8nF6MjznSPIPFcb9p4QOr02wLvWh0a73 bn9A99QPyw+Q7+t9uar2FoL10RIr5FVVMbYFg9e8XfkYFVLfJybppUr88NxOMG7f6cwT 9j/g==
X-Gm-Message-State: APjAAAURINwR61PvAvCjm6O9B3u6RzJypBVELFb9/r8kCp49z7bYoItS qJKmsy4DVu0H4/PYHswCcLRKIuRZVmgUzVdCy69D5w==
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/secdir/VcPHR33jqdxU9jFusCimURieEG8>
Subject: Re: [secdir] [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Nov 2019 02:56:44 -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.
> >
>