Re: [TLS] A flags extension

Benjamin Kaduk <bkaduk@akamai.com> Tue, 26 March 2019 21:54 UTC

Return-Path: <bkaduk@akamai.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 7DC1E120331 for <tls@ietfa.amsl.com>; Tue, 26 Mar 2019 14:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.852
X-Spam-Level:
X-Spam-Status: No, score=-1.852 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, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 VPvav2oc8-Ry for <tls@ietfa.amsl.com>; Tue, 26 Mar 2019 14:53:58 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2F5E120058 for <tls@ietf.org>; Tue, 26 Mar 2019 14:53:58 -0700 (PDT)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x2QLgera027421; Tue, 26 Mar 2019 21:53:58 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to; s=jan2016.eng; bh=wv2jue6MzYHieZNecfL7bxljrxsjv3Go2Mxyzgd5zl0=; b=N3yamF4eUcRaLcvdSjJM/6dG7jCdctXQT4VU+KXzCAqFD+DP8pOKLxqfORxlbrw8ougb 3zezPc+IYH5aZvNFNRCO/W3QuKnW2w7Ec6hxJckYj6e8qPTnVZoQGwJE5vkmTh7sd5Co dnvEuk9jRcJ3k/a4+I+oxSZ8CE3OlbK/PXVzQnCfgRlJ6xW/OC52glL5zQv+N0sscyog ramSlG9tK6hOM7/9THgumT6YhXoKVvG/+Po1Cn98PV0RsOfK01eYAN2PPGGKy3GW1gno FED1bIG8vZrBP9O2gNWFKMgAgCGNHO9np/fr65gy+kM0wSpOIFbTWl+ggaSsotEEcQXW 7w==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2rf6ftkvxt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Mar 2019 21:53:57 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x2QLliIQ014777; Tue, 26 Mar 2019 17:53:56 -0400
Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint1.akamai.com with ESMTP id 2rdg4vp7cs-1; Tue, 26 Mar 2019 17:53:56 -0400
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 492371FC74; Tue, 26 Mar 2019 21:53:56 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1h8u15-000649-GT; Tue, 26 Mar 2019 16:53:55 -0500
Date: Tue, 26 Mar 2019 16:53:55 -0500
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Cc: Hubert Kario <hkario@redhat.com>, tls@ietf.org
Message-ID: <20190326215354.GP10233@akamai.com>
References: <A7EC005E-3463-406B-930F-925B4D2338E4@gmail.com> <1570216.1kCOWNXRrC@pintsize.usersys.redhat.com> <C39ECEA3-3BE1-4A31-AC04-E4A295851675@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <C39ECEA3-3BE1-4A31-AC04-E4A295851675@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-26_14:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=864 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903260147
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-26_14:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=910 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903260147
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kCbTTDrADTvIB4HgZSJAd6dDeiA>
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: Tue, 26 Mar 2019 21:54:01 -0000

On Tue, Mar 26, 2019 at 04:38:11PM +0100, Yoav Nir wrote:
> 
> 
> > On 26 Mar 2019, at 14:45, Hubert Kario <hkario@redhat.com> wrote:
> > 
> > On Monday, 25 March 2019 22:09:35 CET Yoav Nir wrote:
> >> Hi.  Today at the TLS meeting, there was a discussion at the mic about 1-bit
> >> extensions that only serve to indicate support for an optional feature. EKR
> >> commented that such extensions take 4 bytes each and that maybe we need to
> >> replace them with a flags extension.
> >> 
> >> So I threw together a quick -00 draft with an extension that does just that
> >> [1].
> >> 
> >> Comments are welcome.
> > 
> > I don't think that "penny-pinching" the 4 bytes necessary to send a flag is 
> > worth the interoperability problems, and increased complexing of parsing 
> > Client Hello. Especially if we go the route of actual bit flags.
> 
> Right. Which is why I went with a 1-byte encoding rather than a bitstring.
> 
> > I think the likelihood of bugs in that code over the possible bytes saved 
> > makes it a net negative.
> 
> I don’t think so. My encoding is not all that complex.

It would be pretty easy to forget to sort the values (which, btw, maybe we
want to require, to make duplicate detection easier).

-Ben