Re: [TLS] Feedback on draft-ietf-tls-tlsflags

Yoav Nir <ynir.ietf@gmail.com> Fri, 31 January 2020 14:11 UTC

Return-Path: <ynir.ietf@gmail.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 AC44D1200DF for <tls@ietfa.amsl.com>; Fri, 31 Jan 2020 06:11:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 pl6Y2PYaIiQd for <tls@ietfa.amsl.com>; Fri, 31 Jan 2020 06:11:37 -0800 (PST)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 E8B0212008D for <tls@ietf.org>; Fri, 31 Jan 2020 06:11:36 -0800 (PST)
Received: by mail-wm1-x32f.google.com with SMTP id c84so8808899wme.4 for <tls@ietf.org>; Fri, 31 Jan 2020 06:11:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=c+8ocJAYW9sxq8a1H+kcBscA6TtrXMcsMntRK8tXOvk=; b=R7WlEA6m6eOFPNSX1WzJVG3Y6bTVqxaL6gKDnZE1f+BmP6plaJqeNKRYXz4uTCbOP6 JCYmrix+KT65yKK6H/fYXlpmb/Z5qUp9f4EJPZj81baDy5Qu7l7Rxs0NjukfmkDjnMWv 3hKQ3cP2ozbCpg/i4Yg+xfazQUV02p28X4hcCdxPgBa4lW8vP/yXkBei1Lycp3SDCB28 iQGA5KLpjowVptfm97/tgQOilMenve6L1xnJzU0+kyg0ciEGHAuMhaxTmft3/yBYrI3v au4+PsajX+qXtKO44rSVQctBTGhqnvspAMwzRLaR2/mx5WtwrkUEyrLOy2cv93+0zDUD JgmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=c+8ocJAYW9sxq8a1H+kcBscA6TtrXMcsMntRK8tXOvk=; b=g+gF6MldZqpEPKcc5yJqtBRs5kQr0IaCbh2Ll3IElr4ZtBC+jLnE2vdoajP640WdKF oTHkwAyKjcAxZNpUSaalwn2yVHqsxQKXXLf6dhwFnmihf4j57D7HS705FDpVsPYHl0tW WKvuxTaFTcnUBKukvkJjgPZIraQ1yo3ioOGxHQedevx+2GRYNOXrssyeOVBbv1rHFnXh 0iJfJaRMcsYKkCOix2RmzcDLQ4MsY+j1YltI6zZ00zVUsiiOq/0+ElWZy48JVQ4OWUUk VDgdChSdS/Q2iU1r0mfNECUjuxfILf2A/mInbiTet7Aowi6ucvjcHGOtGtUImdQuRFx7 08YA==
X-Gm-Message-State: APjAAAWrKoeINQf0Hi0unZs9t+pdcSNxO/Rp/1qa3deeQlBNvI2qY4Ou jpArb7RJXbMr8z22G5PMsx4=
X-Google-Smtp-Source: APXvYqyZIH/1rkW/Yy8IPNqZyE/0iuzYOIWAJG1Immjto2iwf/E3MyEBRz263DqrZhfPxOX6OWxo2w==
X-Received: by 2002:a7b:cc81:: with SMTP id p1mr11960759wma.62.1580479895444; Fri, 31 Jan 2020 06:11:35 -0800 (PST)
Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id k13sm11659098wrx.59.2020.01.31.06.11.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jan 2020 06:11:34 -0800 (PST)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <6EB7F220-F702-4B39-B994-ACBF4E9528E8@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_964227B9-62C9-4F4E-BD45-D66E9F299C53"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Fri, 31 Jan 2020 16:11:32 +0200
In-Reply-To: <18990e66-1dca-4970-a4a0-a3be7bbc875d@redhat.com>
Cc: tls@ietf.org
To: Hubert Kario <hkario@redhat.com>
References: <6d2a87a9-6d9a-4a39-913b-e9f620275cec@www.fastmail.com> <6F2B5A29-E7EF-4F83-A5F7-A40484D319FB@gmail.com> <a92e4269-cc35-9ecc-6c38-b62f9cecd626@cs.tcd.ie> <18990e66-1dca-4970-a4a0-a3be7bbc875d@redhat.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ld2rY9px71wrxlWfzXhey02vPcc>
Subject: Re: [TLS] Feedback on draft-ietf-tls-tlsflags
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: Fri, 31 Jan 2020 14:11:38 -0000


> On 31 Jan 2020, at 14:26, Hubert Kario <hkario@redhat.com> wrote:
> 
> On Thursday, 30 January 2020 21:08:39 CET, Stephen Farrell wrote:
>> 
>> On 30/01/2020 17:57, Yoav Nir wrote:
>>> Hi folks.
>>> In case you’re not following GitHub, there was an issue with a brief
>>> discussion ([1]) and a resulting pull request ([2]).
>>> If there are no objections by late next week, I will merge the PR.
>> 
>> Allowing 2040 flags seems a bit mad and a possible
>> foot-gun - with a specification required rule that
>> could end up worse than the ciphersuites registry!
>> 
>> Given it's possible to define a tls_flags2 extension
>> if this one runs out, I'd argue to constrain this to a
>> much smaller number of flags - 63 should be plenty
>> I'd say.
>> 
>> That said, it's not that huge a deal since I have
>> a hard time seeing implementers even trying to code
>> for 2040 flags and specification required is the
>> same rule as for extensions.
> 
> well, if the specification says that it can include 2040 flags, an implementation
> must be able to process such an extension
> 
> if the idea of this extension is to reduce the size of ClientHello (the utility
> of which I find questionable), then I don't see a situation where we will really
> need to send old and new extensions at the same time as likely – I expect that
> if we do allow 2040 flags, the extension in 10 or 20 years will commonly include
> just few set bits and plenty of zeros – wasting bandwidth again

An implementation need only support up to the last bit that is meaningful to it.  If the last feature it supports is number 30, there’s no need to read any of the octets beyond the fourth

I think that we can help the situation by partitioning the space as follows:
 - First octet is for standards-track documents coming out of TLS where the draft specifically requests such assignment.  Like if we ever need a renegotiation_info again.
 - Octets 2-4 are for other standards-track documents.
 - Octets 5-7 are for experimental drafts. They don’t get re-assigned if they later become standards track
 - Octets 8 are reserved-private
 - Octets beyond that are in case we need more.

With some luck and some care, most ClientHellos will need no more than the first 4 bytes.

Yoav