Re: [TLS] I-D Action: draft-ietf-tls-tlsflags-00.txt

Yoav Nir <ynir.ietf@gmail.com> Wed, 14 August 2019 17:21 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 831BA120C05 for <tls@ietfa.amsl.com>; Wed, 14 Aug 2019 10:21:25 -0700 (PDT)
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, 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 B0xgSHX2iggq for <tls@ietfa.amsl.com>; Wed, 14 Aug 2019 10:21:23 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 5A1C212018B for <tls@ietf.org>; Wed, 14 Aug 2019 10:21:23 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id k2so25998076wrq.2 for <tls@ietf.org>; Wed, 14 Aug 2019 10:21:23 -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=wBD9rnCyhwLKuO6iU/VJ9Do7ZC3Ar1IIA6o8+oKYquM=; b=WIwADp8DN1gCBnUeiO8P9CIEty4k70EWBxlLIAAiSQ2qmwg6qwwUuLCYYXRRCMC00F BVqTexpFr2aEMqxZ5mrg0TKJZdJVkXdwrApro/7n850WMs6RDex8LuiLzYoQLWzc8avZ VMMbwdrAx12dm7N/mH8kfS8TGyaU/2nz7vfXPaHcDrLQjhux4gufqKZIs5oW3HTYlww/ qW1mcgQMEwIDvOVU0IM7/8JBUI9HI8HwmXGpLXYIA2mkPTrJkuTpU22J4jFIU0dq2MEK O7BxSVx2vbomHzWjrFo+K8kxBGRfwWAlLRhjttRQv3dNJSSRgumogtLx11nFTWp6aejS 8VFw==
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=wBD9rnCyhwLKuO6iU/VJ9Do7ZC3Ar1IIA6o8+oKYquM=; b=WFIlTMErujmgEpQwsVukp0T2yZa95qGfUBDeCrwNB/OdHuyMU3nb7G35qLIusHfoaC qpqWbRuUcduw3+TPXW9P+WGvNuG+PoqyHUogYrklhfigymG6KAdysEFPzkxmPNu97YNR q7fe1S3VCCDQKWK5+4kLI+U56LxMVgGIpK5FkEsV7diuGP9gPKRYqlxWuXzEoVh0mI9o sFUwTXohyiBLFjte6o6qf+CKY+DeriVsxYdLPfDaGNEknIE2NpGyJ0Wph6hrgXrfzc4M 06V5XIObEcRO4OtZTt03c7rIOCutITQ4yVtuSaQBVavAyRK1R2HpuCpGM6GyL4WYXB42 Wjxw==
X-Gm-Message-State: APjAAAXtGq3UKiWb53f/gJ/+a8KC3CyOfm9Zql/M5ENypYlyBm7lCX7z EWdQ9Bdv9ao2vM8usnVU0+A=
X-Google-Smtp-Source: APXvYqyj2MKxXs3mxjjqTvtmbU45Mbv/frHUC3/OEh7l+Lfq8xzeWfBdOsjiF+fcjKemhXo2Dpcchw==
X-Received: by 2002:adf:f28d:: with SMTP id k13mr812763wro.19.1565803281915; Wed, 14 Aug 2019 10:21:21 -0700 (PDT)
Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id m23sm480593wml.41.2019.08.14.10.21.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Aug 2019 10:21:19 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <20190812182519.GA455391@LK-Perkele-VII>
Date: Wed, 14 Aug 2019 20:21:17 +0300
Cc: tls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A9AE6DD-EE01-4DE6-977D-5A8847FB6BE4@gmail.com>
References: <156563213549.17893.514258464688769886@ietfa.amsl.com> <20190812182519.GA455391@LK-Perkele-VII>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/gyZXykcG6ZHF4NqtTFLxRfkZWQk>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-tlsflags-00.txt
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, 14 Aug 2019 17:21:25 -0000


> On 12 Aug 2019, at 21:25, Ilari Liusvaara <ilariliusvaara@welho.com>; wrote:
> 
> On Mon, Aug 12, 2019 at 10:48:55AM -0700, internet-drafts@ietf.org wrote:
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Transport Layer Security WG of the IETF.
>> 
>>        Title           : A Flags Extension for TLS 1.3
>>        Author          : Yoav Nir
>> 	Filename        : draft-ietf-tls-tlsflags-00.txt
>> 	Pages           : 6
>> 	Date            : 2019-08-12
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-tls-tlsflags-00
>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-00
> 
> Two things:
> 
> 
> 1) uint8 flags<0..31>;
> 
> That adds an extra byte that is not technically necressary (because
> extensions have lengths anyway) and limits number of flags to 248
> (which might be enough).

I hope 248 is enough...

> And I do not think the length of flags field can be 0 (if it would
> be, one could just omit the extension).

There could be a future flag that the server sends unsolicited (client-auth-required?).  It’s important for the client to show support for the flags extension to make sure that it understands what the server is sending.

Depends on how we define the semantics in the draft.

> 
> 
> 2) I think the bit order within octets should be reversed
> 
> That is, pack flags so that 0 is LSB of first octet, 7 is MSB of
> first octet, 8 is LSB of second octet and so on.
> 
> Then one can read status flags by index with code like:
> 
> fn read_flag(flags: &[u8], idx: usize) -> bool
> {
>        *flags.get(idx/8).unwrap_or(&0) >> idx%8 & 1 != 0
> }
> 
> (That code will also happily handle out-of-array flags by reading
> them as false.)

Makes sense. I get caught up in visualizing computer memory and protocol messages as a string of bits written from left to right.

> -Ilari
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls