Re: [Tls-reg-review] Adopting tls-flags
Yoav Nir <ynir.ietf@gmail.com> Tue, 20 April 2021 19:53 UTC
Return-Path: <ynir.ietf@gmail.com>
X-Original-To: tls-reg-review@ietfa.amsl.com
Delivered-To: tls-reg-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 98FD33A1572;
Tue, 20 Apr 2021 12:53:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_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 (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 xgV0Ww4VBjxP; Tue, 20 Apr 2021 12:53:53 -0700 (PDT)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com
[IPv6:2a00:1450:4864:20::430])
(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 6AED73A157A;
Tue, 20 Apr 2021 12:53:53 -0700 (PDT)
Received: by mail-wr1-x430.google.com with SMTP id a4so38964402wrr.2;
Tue, 20 Apr 2021 12:53:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=ElCDSfRgsC4feaK3gtdcaeYyuhAVQHvKHSErnWGl0Iw=;
b=oM+ww/KCgv40f7Ic5ezVmQSIK/te0DJh3+s7IqPB9eLfHBWgS6rSpdt8Qf0OFgezIl
FjfFL4c9KzydWVfnIKSgFhcDvWPMmdhfKIWF+4WhRQkbtllyuodFs1FW5WMD2r/rUmqi
e65+6Hnjn18DOmuJay6sZLMcdbaAi/UrwHv179h9mqIsZ/tNj0tkp7vKj/TA+XFLGtNE
fIBKKCWC4Tsr93sGXl6A8UrW7Fk8l3ozcU6AY2DqXxgM6KvQN5cUOkHF1gQLDkg8+9xF
l0MA17kyOzUHWbIjXfPo6RIOSi2eFldFGI+OmKL4HGHRVcMx3pAzyRp/r8PHh1qAnwKA
HCRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=ElCDSfRgsC4feaK3gtdcaeYyuhAVQHvKHSErnWGl0Iw=;
b=fFWLPcggrCaxXRM1yF9RgALErH2Rjoe3jOBNaiTBGmA9AJuX011St8WqTttAYEWmQ2
0/2bN/JiBSvSOjCl5Ec36BlvCrvg1idBS4w52vQGtT3sewXqKv1uIjkdlt2opo2DjiJE
L/LMNNZ28GckfbvzHPmy4DFHY+e4BWYMKGoNIPIikKjpAcnT4/7G/BJcvkcNM9mFhNbH
QuK3kZwsy0+6EAMcRpTEhqEDElHwoFABP1rYI4FP4PN0ZXOWOY6vJTtEKHH+E//Jznnf
/NXB8sPTWLsEIifi3+I1wISMvhPuRYzHxovdR6vn02ZY8gojGn5GbdeuSO0OoPcMay8S
gztQ==
X-Gm-Message-State: AOAM532xsMNBltK3hAOzc43e3LkrLboe31LafBLgr5M273XcNqUvzcut
mwqaUWdr57aoN4+txioQVk0=
X-Google-Smtp-Source: ABdhPJwFrgZtyiwF9/anXwTJTYkj9T/nr7/QWxJGKa3Uj7HV3+YNNuiCHDNrXRa7oxE5HArkGetffQ==
X-Received: by 2002:adf:fb91:: with SMTP id a17mr23151339wrr.118.1618948430567;
Tue, 20 Apr 2021 12:53:50 -0700 (PDT)
Received: from [192.168.1.19] ([46.120.57.183])
by smtp.gmail.com with ESMTPSA id l8sm4206622wme.18.2021.04.20.12.53.48
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Tue, 20 Apr 2021 12:53:49 -0700 (PDT)
Content-Type: text/plain;
charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <44C284C4-163C-431D-91B4-ED60AE2B5C40@sn3rd.com>
Date: Tue, 20 Apr 2021 22:53:45 +0300
Cc: Victor Vasiliev <vasilvv@google.com>, Benjamin Kaduk <kaduk@mit.edu>,
Chris Wood <caw@heapingbits.net>, TLS DEs <tls-reg-review@ietf.org>,
draft-ietf-tls-cross-sni-resumption@ietf.org,
TLS Chairs <tls-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <ECACEC20-871B-4333-8D1F-08A44C34599E@gmail.com>
References: <CAAZdMadAGa=X5+ktAUjr-=fvxrpQwRfERHbpR4+6KfXeiWxAGw@mail.gmail.com>
<7fb3a536-6716-4f55-82ed-2c4b96669166@www.fastmail.com>
<b1a39bbf-23b8-472c-9565-20479ee7b262@www.fastmail.com>
<CAAZdMad7A3fJG9GyNrXgSnsnC-wHN5_V4wpaOqWwAtUGzWtbsw@mail.gmail.com>
<1f78ab86-8e27-4d8a-b670-b1a5d6432eb0@www.fastmail.com>
<20210319203859.GF79563@kduck.mit.edu>
<E37616E0-5199-4258-BCAB-DFF9B3C5C14C@gmail.com>
<3c7eeed5-a559-4f12-a2a6-19b7cc41c2e7@www.fastmail.com>
<a91a607d-ae01-46ac-bea8-2f78a5200665@www.fastmail.com>
<FA2A69DB-2AA1-4605-971A-A76B8177EF1E@gmail.com>
<20210330143102.GZ79563@kduck.mit.edu>
<e8c96ac1-b9cc-4aa2-8d35-bba149dffed7@www.fastmail.com>
<44C284C4-163C-431D-91B4-ED60AE2B5C40@sn3rd.com>
To: Sean Turner <sean@sn3rd.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls-reg-review/lEcXSdh4YYtlliWc5_JctuVpgxM>
Subject: Re: [Tls-reg-review] Adopting tls-flags
X-BeenThere: tls-reg-review@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TLS REVIEW <tls-reg-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls-reg-review>,
<mailto:tls-reg-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls-reg-review/>
List-Post: <mailto:tls-reg-review@ietf.org>
List-Help: <mailto:tls-reg-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls-reg-review>,
<mailto:tls-reg-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Apr 2021 19:53:59 -0000
We haven’t. Mea culpa Victor: How about you make your document say that the number 8 has been assigned from the TLS Flags IANA registry. I will update the tls-flags document to have an initial content of the registry with just this 8 value. Of course section 3 of the cross-sni-resumption would have to be changed to reflect that it uses a flag and not a new extension. My suggestion for the content of the IANA considerations section should be something like: IANA has assigned a flag from the TLS Flags registry with the following: * Value: 8 * Name: resumption_across_names * Message: NST * Recommended: N * Reference: This document Is this acceptable? Yoav > On 20 Apr 2021, at 17:52, Sean Turner <sean@sn3rd.com> wrote: > > Hi! Checking back in on this one. Have we decided what changes to make where? > > Cheers, > spt > >> On Mar 30, 2021, at 10:32, Christopher Wood <caw@heapingbits.net> wrote: >> >> I totally do not feel strongly about the outcome here. I would just like to see this resolved. >> >> Victor, Yoav: can you please coordinate and make changes (one way or another)? >> >> Thanks! >> Chris >> >> On Tue, Mar 30, 2021, at 7:31 AM, Benjamin Kaduk wrote: >>> I am also unsure what was requested of whom ... I think my proposal was >>> that the cross_sni_resumption value would be listed in the tlsflags draft >>> and also used in the cross-sni-resumption draft, and we can work out the >>> details based on which one is published first. >>> >>> -Ben >>> >>> On Tue, Mar 30, 2021 at 04:26:18PM +0300, Yoav Nir wrote: >>>> Are you waiting for Ben to clarify the suggestion or for me to say if it will work? >>>> >>>> It works for me either way. >>>> >>>>> On 30 Mar 2021, at 16:15, Christopher Wood <caw@heapingbits.net> wrote: >>>>> >>>>> Bump! >>>>> >>>>> On Mon, Mar 22, 2021, at 7:04 AM, Christopher Wood wrote: >>>>>> On Sat, Mar 20, 2021, at 9:57 PM, Yoav Nir wrote: >>>>>>> You mean add the cross_sni_resumption value to the tlsflags draft? >>>>>> >>>>>> I don't think that was the suggestion. I understand the proposal to be: >>>>>> >>>>>> 1. tls-flags owns the registry and its initial contents, and it's >>>>>> initially empty empty. >>>>>> 2. cross-sni-resumption defines the first registry value for tls-flags, >>>>>> with value 8. >>>>>> >>>>>> Did I misunderstand? If not, would that work? >>>>>> >>>>>> Best, >>>>>> Chris >>>>>> >>>>>>> Sure. We can do that, if we’re sure that the cross-sni-resumption draft >>>>>>> is getting approved in this form. I don’t think there has been a WGLC >>>>>>> for it yet. >>>>>>> >>>>>>> Also, section 4.1 of the TLSFLAGS draft has this advice: >>>>>>> >>>>>>> 4.1. Guidance for IANA Experts >>>>>>> >>>>>>> This extension allows up to 2040 flags. However, they are not all >>>>>>> the same, because the length of the extension is determined by the >>>>>>> highest set bit. >>>>>>> >>>>>>> We would like to allocate the flags in such a way that the typical >>>>>>> extension is as short as possible. The scenario we want to guard >>>>>>> against is that in a few years some extension is defined that all >>>>>>> implementations need to support and that is assigned a high number >>>>>>> because all of the lower numbers have already been allocated. An >>>>>>> example of such an extension is the Renegotiation Indication >>>>>>> Extension defined in [RFC5746]. >>>>>>> >>>>>>> For this reason, the IANA experts should allocate the flags as >>>>>>> follows: >>>>>>> >>>>>>> o Flags 0-7 are reserved for documents coming out of the TLS working >>>>>>> group with a specific request to assign a low number. >>>>>>> >>>>>>> o Flags 8-31 are for standards-track documents that the experts >>>>>>> believe will see wide adoption among either all users of TLS or a >>>>>>> significant group of TLS users. For example, an extension that >>>>>>> will be used by all web clients or all smart objects. >>>>>>> >>>>>>> o Flags 32-63 are for other documents, including experimental, that >>>>>>> are likely to see significant adoption. >>>>>>> >>>>>>> o Flags 64-79 are not to be allocated. They are for reserved for >>>>>>> private use. >>>>>>> >>>>>>> o Flags 80-2039 can be used for temporary allocation in experiments, >>>>>>> for flags that are likely to see use only in very specific >>>>>>> environments, for national and corporate extensions, and as >>>>>>> overflow, in case one of the previous categories has been >>>>>>> exhausted. >>>>>>> >>>>>>> >>>>>>> So IMO this is more fitting to receive the number 8 rather than the >>>>>>> number 1. That is, unless the WG wants to make the case that this flag >>>>>>> extension is going to be present in most ClientHello messages from now >>>>>>> on. >>>>>>> >>>>>>> Yoav >>>>>>> >>>>>>>> On 19 Mar 2021, at 22:38, Benjamin Kaduk <kaduk@mit.edu> wrote: >>>>>>>> >>>>>>>> The draft that creates the registry owns the initial registry contents >>>>>>>> until the registry itself is created. >>>>>>>> >>>>>>>> So, just put the value in the draft's source, and try to avoid re-using a >>>>>>>> number for different things during the draft's time as a draft. >>>>>>>> >>>>>>>> -Ben >>>>>>>> >>>>>>>> On Fri, Mar 19, 2021 at 01:26:10PM -0700, Christopher Wood wrote: >>>>>>>>> + tls-reg-review >>>>>>>>> >>>>>>>>> Good question! Since this is a new registry, I don't see any problem with grabbing 1 to populate it. The registry experts may have a better answer though. >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Chris >>>>>>>>> >>>>>>>>> On Thu, Mar 18, 2021, at 5:06 PM, Victor Vasiliev wrote: >>>>>>>>>> Do I actually get to just use 1, or do I need to ask you to do the >>>>>>>>>> early allocation process? >>>>>>>>>> >>>>>>>>>> On Tue, Mar 16, 2021 at 9:50 PM Christopher Wood <caw@heapingbits.net> wrote: >>>>>>>>>>> Friendly bump! >>>>>>>>>>> >>>>>>>>>>> On Mon, Mar 1, 2021, at 7:52 AM, Christopher Wood wrote: >>>>>>>>>>>> Hi Victor, >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Mar 1, 2021, at 7:39 AM, Victor Vasiliev wrote: >>>>>>>>>>>>> Hi Chris, >>>>>>>>>>>>> >>>>>>>>>>>>> This makes sense. I will update the draft some time after the upcoming >>>>>>>>>>>>> IETF. Do you want to just add a codepoint reserved for cross-domain >>>>>>>>>>>>> resumption into the draft, or how does that work? >>>>>>>>>>>> >>>>>>>>>>>> Good question. I suspect your draft would just add, in the IANA >>>>>>>>>>>> considerations section, something like this: >>>>>>>>>>>> >>>>>>>>>>>> ~~~ >>>>>>>>>>>> This document requests that IANA create a new entry in "TLS Flags" >>>>>>>>>>>> registry with the following parameters: >>>>>>>>>>>> >>>>>>>>>>>> - Value: 1 >>>>>>>>>>>> - Flag Name: "cross_sni_resumption" (or whatever you want to name it) >>>>>>>>>>>> - Message: NewSessionTicket >>>>>>>>>>>> - Recommended: Y >>>>>>>>>>>> - Reference: This document >>>>>>>>>>>> ~~~ >>>>>>>>>>>> >>>>>>>>>>>> (See https://tools.ietf.org/html/draft-ietf-tls-tlsflags-04#section-4) >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> (sorry for late response, just noticed the part about the draft submission deadline) >>>>>>>>>>>> >>>>>>>>>>>> No problem! >>>>>>>>>>>> >>>>>>>>>>>> Best, >>>>>>>>>>>> Chris >>>>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> tls-reg-review mailing list >>>>>>>>> tls-reg-review@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/tls-reg-review >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> tls-reg-review mailing list >>>>>>>> tls-reg-review@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/tls-reg-review >>>>>>> >>>>>> >>>> >>> >
- Re: [Tls-reg-review] Adopting tls-flags Christopher Wood
- Re: [Tls-reg-review] Adopting tls-flags Benjamin Kaduk
- Re: [Tls-reg-review] Adopting tls-flags Yoav Nir
- Re: [Tls-reg-review] Adopting tls-flags Christopher Wood
- Re: [Tls-reg-review] Adopting tls-flags Christopher Wood
- Re: [Tls-reg-review] Adopting tls-flags Yoav Nir
- Re: [Tls-reg-review] Adopting tls-flags Benjamin Kaduk
- Re: [Tls-reg-review] Adopting tls-flags Christopher Wood
- Re: [Tls-reg-review] Adopting tls-flags Sean Turner
- Re: [Tls-reg-review] Adopting tls-flags Yoav Nir
- Re: [Tls-reg-review] Adopting tls-flags Yoav Nir
- Re: [Tls-reg-review] Adopting tls-flags Victor Vasiliev
- Re: [Tls-reg-review] Adopting tls-flags Yoav Nir
- Re: [Tls-reg-review] Adopting tls-flags Christopher Wood
- Re: [Tls-reg-review] Adopting tls-flags Victor Vasiliev
- Re: [Tls-reg-review] Adopting tls-flags Yoav Nir