Re: [TLS] A flags extension

Eric Rescorla <ekr@rtfm.com> Wed, 27 March 2019 13:47 UTC

Return-Path: <ekr@rtfm.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 C7F7D1200E0 for <tls@ietfa.amsl.com>; Wed, 27 Mar 2019 06:47:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 y28dfQMTD3VC for <tls@ietfa.amsl.com>; Wed, 27 Mar 2019 06:47:04 -0700 (PDT)
Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (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 94ADA12000F for <tls@ietf.org>; Wed, 27 Mar 2019 06:47:03 -0700 (PDT)
Received: by mail-lf1-x143.google.com with SMTP id u2so11333909lfd.4 for <tls@ietf.org>; Wed, 27 Mar 2019 06:47:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Dr2vaDciHlGYCn61GqC7gGDoz7KWkxVNBXz9K43uBvc=; b=ZVkzoAH+KBIZ3Iq3J9HsicGQLcWcaRalnwAWjb1ZR5grSAJlfKIplfrfrSsJaEtbBw 2uaqJhZDopFNBo04rBsVpXm0AM4GG/3tHBGD6cLaAwOeESzP0R0kmPDR9D1HsL4508zx lCBO5r4I1t6facda0iyu1IdIzfz9yeG0h52oDiXd5v0VpVvw3ubm6ddmnQ/jjxNq/Bgj NDS6e31hfapuo9DUHv3QkxhLg3B4Nv41+3RjpUPg67f46svZoPjUVd1N4jS5LLBKWQhy yQo3LtKhYRsRgHzjrsKjq2D17VvSNAGfz7hmfHtIic1OG5gK2xT7uGtPBvM72/vQ41u+ /4fw==
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=Dr2vaDciHlGYCn61GqC7gGDoz7KWkxVNBXz9K43uBvc=; b=W3sZznYJP4ITWFBcnX5+e7QHzSc3oNLtqMMEzc0ttcr3c5noZ9yZiMLCAKlkXpsePo Rl2B0qHQklMBJvnAws+AzXbigVFIlpmBswE/yQBsvWZDLBU4Io5982lqL5YezGyw0tgb El+O2/YnLFW4R4sOK4Hyn+EthBwd5rtOIRZWFEvD3Cw6Xo5aPY0oFomQsst7WmhvJI3K Vkf4z64IqVYnEhH58aM08oML0NwzfMKWhhbq5C0EQZiUnPCrniTS/c0Qkmc5S6OBVRxR jczzf6ihAVcaxNE8s23O9coTfC/XdYE/71JcTEGbJlYsvL9oOARk+PmSzUt+hGOtfdAD TizA==
X-Gm-Message-State: APjAAAWMjx6KqXJHgCWeKjfU/gnnZ8d+rdxjLMnowFkmsrplKqKWQXey voS8wplNvssNXJIefSV1YaM/spq1E+pBnMWBNfAVC+OZ
X-Google-Smtp-Source: APXvYqw+Hj7cAY9maXqSE5WyHkkS1blbkpEmanIjj14vc2FjNzZCJKUq39ZiWd/3663ZBEPifZMBHC5Kt72SwlGUIq0=
X-Received: by 2002:ac2:518b:: with SMTP id u11mr20049774lfi.123.1553694421711; Wed, 27 Mar 2019 06:47:01 -0700 (PDT)
MIME-Version: 1.0
References: <A7EC005E-3463-406B-930F-925B4D2338E4@gmail.com> <B0FF00D7-8727-4371-8DAA-AD2A920504F8@akamai.com> <2e5a5623-7de9-4f12-b699-b0b248432f96@www.fastmail.com> <F5AD3A62-C0D1-49F7-8D10-27A7DA92DCCC@gmail.com> <be8f455bf446d6db3ba81a8ac98ed9d485cc43de.camel@redhat.com> <C1694B79-1CA2-44B5-A77E-8F12FE0C785D@gmail.com> <ac26657f9614afb3880135efeb06265393012777.camel@redhat.com> <87o95wfthk.fsf@fifthhorseman.net> <8CCF5B81-9873-41AB-B062-AD109365A80A@gmail.com> <dcdcba29-9571-4747-880e-2aba9f649775@www.fastmail.com>
In-Reply-To: <dcdcba29-9571-4747-880e-2aba9f649775@www.fastmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 27 Mar 2019 06:46:23 -0700
Message-ID: <CABcZeBOiQUz+9M4yvt2Ri0_K+K4MOupAz=W4MUEL1KxYgpzrEg@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001894b2058513aca1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/tQw-PwgukMJXLOtBk31_vpXqJPA>
Subject: Re: [TLS] A flags extension
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: Wed, 27 Mar 2019 13:47:07 -0000

Of course, at some point it starts to make sense to do RLE.

-Ekr


On Wed, Mar 27, 2019 at 6:43 AM Martin Thomson <mt@lowentropy.net> wrote:

> Why not go all in - make this a byte string and start from 0x80 in the
> first byte.  When we define the 9th flag, we add another byte.  Then you
> have up to 2040 flags (though it might pay to split the space before that).
>
> struct {
>   opaque<1..255> flags;
> } Flags;
>
> Otherwise, the first adopter of this pays 10 bytes where they would
> previously have paid 4.  Obviously there is a network effect at the third.
> Since I'm writing a draft that will aim to depend on this, I have a vested
> interest in using this.
>
> If you wanted to make it more attractive to me, then maybe porting some of
> the existing flags across might make it more appealing.
>
> On Wed, Mar 27, 2019, at 13:08, Yoav Nir wrote:
> >
> >
> > > On 27 Mar 2019, at 12:26, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
> wrote:
> > >
> > > On Wed 2019-03-27 10:52:20 +0100, Nikos Mavrogiannopoulos wrote:
> > >> Right. What about defining a set of extensions (e.g., 2 extensions) of
> > >> flags as:
> > >>
> > >> struct {
> > >>  uint64 flags;
> > >> } Flags;
> > >
> > > If we're going to be doing this kind of bit-shaving, this is the way to
> > > go, starting with a single CommonFlags extension -- and maybe even a
> > > uint32 or uint16, with the bitfield registry under tight WG control. If
> > > we exhaust that space, then we just define a CommonFlags2 extension.
> > >
> > > If someone wants an experimental boolean extension to play with, they
> > > can always use an empty extension. They can apply for a bit in
> > > CommonFlags if they find that the compactness is warranted.
> > >
> >
> > OK. You got me convinced.
> >
> > In the spirit of revising quickly and revising often, I’ve uploaded
> version -01:
> >
> > HTML: https://datatracker.ietf.org/doc/html/draft-nir-tls-tlsflags
> > DIFF: https://www.ietf.org/rfcdiff?url2=draft-nir-tls-tlsflags-01
> >
> > Yoav
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>