[TLS] TLSFlags ambiguity

Jonathan Hoyland <jonathan.hoyland@gmail.com> Fri, 15 September 2023 17:37 UTC

Return-Path: <jonathan.hoyland@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 5D9F6C15108B for <tls@ietfa.amsl.com>; Fri, 15 Sep 2023 10:37:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrP9F3msIFPM for <tls@ietfa.amsl.com>; Fri, 15 Sep 2023 10:37:02 -0700 (PDT)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F1A6C151061 for <tls@ietf.org>; Fri, 15 Sep 2023 10:36:55 -0700 (PDT)
Received: by mail-pf1-x42d.google.com with SMTP id d2e1a72fcca58-68fbd31d9deso2307602b3a.3 for <tls@ietf.org>; Fri, 15 Sep 2023 10:36:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1694799415; x=1695404215; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=uGYiTkuFULilkZrCbfCwRDsNkmcvyVhYsHJ9gaLaurs=; b=VFJc49vOX3Nr3I+eLiGgLsfl09iT0qxvMAZRr5ev7wopyHVGLS+Eq/MD2j67NrS6Qx yPTXIXVODJPSbwBhLhi2Q6sbxkH+xtdHnzmB7nuvNHjFykja9D1qZvulz7z5GSggfDVG OyYyhM9Xy7oJKeXWcEaGOXv9RGZAlktINtt49Z+wXQn6z/V74FxjgbibxMzppwHw9Zjx 5uk0DSZeHSks04UkIPSfNXA0ENb3+Pn/yEytOtimZxXf76yi0iWMg3SyvvxGFkxJC6Gl qlO0k/kolfoNiHL1DnMo0vFQF7o+DSxast2gg+ZSoXUctZf9NCox4faw5vxBy+b3z5Mk Zfpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694799415; x=1695404215; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=uGYiTkuFULilkZrCbfCwRDsNkmcvyVhYsHJ9gaLaurs=; b=ZEeg/XCEi0ZQ9K8E4uwEPKMvur2tQNV5vF75Hd27krL2/5XIVeZ+LSOi78RnOKwcYq 1i4U8jl35ybPd1LhJET3YK5yodWlpbBnAJLeHlbt19nzk9Rh99K/LMrH4ePg3JpDlaAt 3JL9Zwih0pZUESnIQNVovWiTpCA/4I+tq4nUDhMtB3DQpUSkl7JgYJytTNIvLWcdHmfk 87/9fpHCFQhDBCkjbafaWfyZO2RjGP1BNcdmLhIJc5eUjmSQaBMzDHMfT72Lhf5Izpyr nOK/YGes15Eio7AqkiMSIZ1o26qemVwZmzZF52Aky1sPqbAAHg9tMjjtLXcu5r9itvAP 5sIw==
X-Gm-Message-State: AOJu0YyZjCWEGP2m3M5pUp2zRdLDX/l98TYhYHbifivTZgWmRqF1k8IB t0eAwTR9RjL2fnleSBihTGUsJWoEPNpMt1WcvLBYivYvbYYzeA==
X-Google-Smtp-Source: AGHT+IFbpqoHGIKWcfgCx3ZPcAQkZiC1ox6WfLah2V4MybQSpmLarx+f/J6PL7VCWi5pKJJCLuWhaN9NPc5OOn5wx3I=
X-Received: by 2002:a17:90b:1049:b0:268:d716:4b62 with SMTP id gq9-20020a17090b104900b00268d7164b62mr2145188pjb.0.1694799414404; Fri, 15 Sep 2023 10:36:54 -0700 (PDT)
MIME-Version: 1.0
From: Jonathan Hoyland <jonathan.hoyland@gmail.com>
Date: Fri, 15 Sep 2023 18:36:42 +0100
Message-ID: <CACykbs2EtsmB-V0BjgYeo4GNeUSnZ1jKo6eKQMOVMwsShPaw8w@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000fad170605693de6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/G-f6_Oxv6fJekfgVmLDVS-gcbvQ>
Subject: [TLS] TLSFlags ambiguity
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
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, 15 Sep 2023 17:37:06 -0000

Hi TLSWG,

I'm working on implementing the TLS Flags extension
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-12>, and I
just wanted to clarify a potential ambiguity in the spec.

In Section 2 the spec says:
Such documents will have to define which bit to set to show support, and
the order of the bits within the bit string shall be enumerated in network
order: bit zero is the high-order bit of the first octet as the flags field
is transmitted.

And also gives the example for encoding bit zero:
For example, if we want to encode only flag number zero, the FlagExtension
field will be 1 octet long, that is encoded as follows:

   00000001

In which it seems that the low-order bit of the first octet represents zero.

I have no preference either way, but when transmitted on the wire,
should flag 0 be transmitted as

0x01 or 0x80?

Regards,

Jonathan