Re: [Tls-reg-review] Adopting tls-flags
Christopher Wood <caw@heapingbits.net> Thu, 13 May 2021 18:00 UTC
Return-Path: <caw@heapingbits.net>
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 3A0A53A0843; Thu, 13 May 2021 11:00:16 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=heapingbits.net header.b=K9jWDqT2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZefmYj9M
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 pXu5BKfoAsUZ; Thu, 13 May 2021 11:00:11 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6343A083B; Thu, 13 May 2021 11:00:10 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8DC4F5C00EC; Thu, 13 May 2021 14:00:06 -0400 (EDT)
Received: from imap4 ([10.202.2.54]) by compute4.internal (MEProxy); Thu, 13 May 2021 14:00:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm1; bh=Sv sB+xtjYOz5ULKStdpIO0i/wUWpGOrMWShFiybietw=; b=K9jWDqT2qFYO30XdP6 3C+947niYXbPs0Zb72Gl0d4fzMYXY69XSZvcfjIns+AeBkZ37gWq+SEnfzfn3oyG 3pZJWC2ndACkKEU/Roj63XMOES2ZVcAnnvdhxvMllTWVrKRRbm5xjVDWRCj6RAOU wZNVAhEdj5B/9cBs0ww1XfjVZ4+Rr8AgjtH4mBRoATFUEJtVQSz4U26SIAEXSoyJ P6Zy73LPi2HWEPny4SqjldCew7qxuvh4We2BmJAU3AmbqMPxVMtHArzB37v9DgG1 oaeNMZWl9oeHKPl8WzRX1lmtH35fNK6g+fIEWry8tb2IxLPDuZXCT/AdV2Wiq4yE FJLQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=SvsB+xtjYOz5ULKStdpIO0i/wUWpGOrMWShFiybie tw=; b=ZefmYj9MuBb2c7sIb8j7RKcLsekcbzjOcovib7bh4AxLbMEZfT3t88FMh lXTZJRDRtJj5CG9EbpTdsG35ZVvJxk3Juts6UO8Cwt+roCYRRZhS394NHWuz8Kvh fJHz2AXC2ZDKk1jLP47eNfS9OuLN27M8Bph3tX8cix16iG0hTyPvHR9R7FTl+iP2 LziKg+tLV6AA2caGZDwYtSC0utkP7tsRtvaLKJ0tGkq4g8aXd7Otp1d7AiE5mfgg cHJ06YxPd6/bWn6d68JYo4SJqcdJi5BdzQuFztuj6dqoH3sz96SluNMX/RHZNEsL LIWDA/7tiwyMzrl3EfqVIPLA+ycuw==
X-ME-Sender: <xms:JWmdYFhu1SQeQEBaV4AkfCYqrqYSvQvcrye0ClYEshor06daDgPSTw> <xme:JWmdYKAnGcFxPKEq53hL0vcrHSXttl1ex63czzTyq6KH8eRM9wz1l4UM7euXtubdk zlxLUjqRa24WtwAtJ8>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdehgedguddulecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfjughrpefofgggkfgjfhffhffv ufgtgfesthhqredtreerjeenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhoug dfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvtheqnecuggftrfgrthhtvghrnhep hfejleetgfegfffhvdejleeglefgiefgleelueefjeeiheffvdffffdvvdegffdvnecuff homhgrihhnpehgihhthhhusgdrtghomhdpghhithhhuhgsrdhiohdpihgvthhfrdhorhhg necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheptggrfi eshhgvrghpihhnghgsihhtshdrnhgvth
X-ME-Proxy: <xmx:JWmdYFH3LxCr1s5kwutQDJNSbzDEUg3ybZH6j--MeHuzUSTgBGsU0g> <xmx:JWmdYKR_Ln4A3l9UrbityzqVGEY_fxSq8AC12uMCsaaOTCRqsEPghg> <xmx:JWmdYCx17Z8LBfpikyXGKumsidfy37ZsoYBwAJX51XDb-9Vfoz_dSQ> <xmx:JmmdYMuV2ruP1sF3jZb-jDMEMCransEMHMsuxgfMX59oebDNB3TpFA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id DFD0B160065; Thu, 13 May 2021 14:00:05 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-448-gae190416c7-fm-20210505.004-gae190416
Mime-Version: 1.0
Message-Id: <e2395168-083c-4431-af6c-002c676344b1@www.fastmail.com>
In-Reply-To: <6CE066ED-5AC8-4896-9589-7D1383197A56@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> <ECACEC20-871B-4333-8D1F-08A44C34599E@gmail.com> <45C3C6E4-B209-4512-A41C-A93CDFAB8ACD@gmail.com> <CAAZdMad6LB5L+sr3qfUvhUONhY0OCeYQSSdUsmEsr+WTtX_JZA@mail.gmail.com> <6CE066ED-5AC8-4896-9589-7D1383197A56@gmail.com>
Date: Thu, 13 May 2021 10:59:42 -0700
From: Christopher Wood <caw@heapingbits.net>
To: Yoav Nir <ynir.ietf@gmail.com>, Victor Vasiliev <vasilvv@google.com>
Cc: Sean Turner <sean@sn3rd.com>, Benjamin Kaduk <kaduk@mit.edu>, "tls-reg-review@ietf.org" <tls-reg-review@ietf.org>, draft-ietf-tls-cross-sni-resumption@ietf.org, TLS Chairs <tls-chairs@ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls-reg-review/X-ACQrfGWtz85qcWQ4qp3x8UjtQ>
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: Thu, 13 May 2021 18:00:25 -0000
>From the side lines: thanks, all! On Thu, May 13, 2021, at 10:36 AM, Yoav Nir wrote: > Looks good. I’ve added this to my working copy. Let me know when you > upload yours, and I’ll upload mine. > > https://github.com/tlswg/tls-flags/blob/master/draft-ietf-tls-tlsflags.xml > > Yoav > > > On 12 May 2021, at 20:30, Victor Vasiliev <vasilvv@google.com> wrote: > > > > Sorry, I was on a sick leave for most of April, and this fell through the cracks. > > > > I updated the editor's copy of the draft: <https://vasilvv.github.io/tls-cross-sni-resumption/draft-ietf-tls-cross-sni-resumption.html>. Please take a look at it; if you're okay with the wording I am using, I'll upload this to the datatracker. > > > > Thanks, > > Victor. > > > > On Sun, May 9, 2021 at 4:17 PM Yoav Nir <ynir.ietf@gmail.com> wrote: > >> Victor? > >> > >> > On 20 Apr 2021, at 22:53, Yoav Nir <ynir.ietf@gmail.com> wrote: > >> > > >> > 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 Benjamin Kaduk
- 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 Christopher Wood
- 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 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