From sean@sn3rd.com Mon Mar 18 00:02:33 2024 Return-Path: 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 5724BC06F226 for ; Mon, 18 Mar 2024 00:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, 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 (1024-bit key) header.d=sn3rd.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 LqHMjepHSGeE for ; Mon, 18 Mar 2024 00:02:24 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 D0584C15107A for ; Mon, 18 Mar 2024 00:01:33 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id d9443c01a7336-1dd10a37d68so32452635ad.2 for ; Mon, 18 Mar 2024 00:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; t=1710745293; x=1711350093; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=pXk26QDDYDelTzXU/0Ihlv6Q0oou/lO4GoASPrreuU0=; b=RRjrF/iVQZDsw1dgDxZRlawNOqJDUruU7A7c9GhK9S1AgxevxPC+kSLABTYAFu4XLa LT0PyIajvMXCcaGV29rgxk9pF++QDeOtPiJxuO1umWGEXyZsf2kyTnI0jflUQSX5Czqd StQOD7DWhd/etj0Fivud4uuE5nOoo3Rq2dWoM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710745293; x=1711350093; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pXk26QDDYDelTzXU/0Ihlv6Q0oou/lO4GoASPrreuU0=; b=tZ+Ofj2RRwyYVM1h1lZ6/k4GXSizmL6e8ky7BtNnSk1SYi1DybavTOzGojtGjtsC2S C0LaszTQQPXFEy+eEBgELod67VXkxxl0Nu1jeX0roPHXlnm7HovLHQyf5IwYjF7ATWE6 fnlnxmLqJLl9t22ZhP8hHgIcLtRSUwjh2yQA4z7TXU6ka0x9O+yZofu6HTafgoBgKE5Y yOg2FxjeZchsQHjVLTnFBZbWN/Ker0hhH7hn9rvVUdIHD50o6+MZbK2megUZxPtnES3N kepcVjieM8wLGpdoaL6N4sN2hKeAvOWeA/R+wThmkKJ/W/tTSu4rUyfUGmKqjVpBw3ud lDzQ== X-Forwarded-Encrypted: i=1; AJvYcCUZTaE30F2vi1yBChuxELGrJO2YpMnYqng54/gD3yDbcoKcqlF/xrAMgxn/bucmQ8Y2fa2S+cl8p6cFpiQ= X-Gm-Message-State: AOJu0Yz3AD1gg5tmKbuG4A9BGa5bn44+WWNo1EXqYP8qPh6yN8RB1ua6 r8JutjI3acHc46PV7/wl598/2Nbyudi5ucxjIi0j64sHRaQ9TdkW6Lq2MbqNk7oV4sZgVproApZ l X-Google-Smtp-Source: AGHT+IFAgz/9iDULMgo0GBxAdu7bnT5xG96mt6W8eDKI5LY/gmOORzAD5iwu61/86YvxNMBituhgHQ== X-Received: by 2002:a17:902:d2c4:b0:1de:fc12:f66c with SMTP id n4-20020a170902d2c400b001defc12f66cmr8808927plc.27.1710745292588; Mon, 18 Mar 2024 00:01:32 -0700 (PDT) Received: from smtpclient.apple ([2001:67c:370:128:7013:4bce:17b9:40ba]) by smtp.gmail.com with ESMTPSA id u12-20020a170903124c00b001dd66642652sm8424827plh.190.2024.03.18.00.01.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Mar 2024 00:01:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) From: Sean Turner In-Reply-To: Date: Mon, 18 Mar 2024 17:01:29 +1000 Cc: Jonathan Hoyland , Yoav Nir , TLS List Content-Transfer-Encoding: quoted-printable Message-Id: <723EEC28-1AC1-493E-8F89-CDB2ABCF0A81@sn3rd.com> References: To: David Benjamin X-Mailer: Apple Mail (2.3654.120.0.1.15) Archived-At: Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2024 07:02:33 -0000 I just threw in a couple of PRs to align this I-D with 8446bis & = 8447bis, but forgot to add this issue. I have corrected this now so = that we won=E2=80=99t forget again: https://github.com/tlswg/tls-flags/issues/36 spt > On Mar 17, 2024, at 13:53, David Benjamin = wrote: >=20 > Did this ever get resolved? I noticed that there was a draft-13 cut, = but the issue Jonathan pointed out was still there. >=20 > Looking at Section 2 again, it's actually even goofier than the = original email suggests. Section 2 first says: >=20 > > The FlagExtensions field contains 8 flags in each octet. The length = of the extension is the minimal length that allows it to encode all of = the present flags. Within each octet, the bits are packed such that the = first bit is the least significant bit and the eighth bit is the most = significant. >=20 > This is LSB first. Then there's an example, which is also LSB first: >=20 > > 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 >=20 > So that's all consistent. But then the last paragraph of section 2 = says: >=20 > > Note that this document does not define any particular bits for this = string. That is left to the protocol documents such as the ones in the = examples from the previous section. 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. >=20 > This says it's MSB first for some reason. But this is not only = inconsistent, but also redundant with the text at the start of section = 2. It seems to me we could simply delete the redundant text and move on: >=20 > > Note that this document does not define any particular bits for this = string. That is left to the protocol documents such as the ones in the = examples from the previous section. Such documents will have to define = which bit to set to show support. >=20 > David >=20 > On Wed, Sep 27, 2023, 17:50 David Benjamin = wrote: > Nice catch! I agree those don't match. I think bit zero should be the = least-significant bit. That is, we should leave the examples as-is and = then fix the specification text. >=20 > Ordering bits MSB first doesn't make much sense. Unlike bytes, there = is no inherent order to bits in memory, so the most natural order is the = power of two represented by the bit. Put another way, everyone accesses = bit N by ANDing with 1 << N and that's least-significant bits first. I = can think of a couple systems (DER, GCM) that chose to order bits = most-significant first and both have caused endless confusion and = problems. (It's particularly bad for GCM which is actually representing = a polynomial, but then messed up the order. Let's not repeat this = blunder.) >=20 > On Fri, Sep 15, 2023 at 1:37=E2=80=AFPM Jonathan Hoyland = wrote: > Hi TLSWG, >=20 > I'm working on implementing the TLS Flags extension, and I just wanted = to clarify a potential ambiguity in the spec. >=20 > 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. >=20 > 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. >=20 > I have no preference either way, but when transmitted on the wire, = should flag 0 be transmitted as=20 > 0x01 or 0x80? >=20 > Regards, >=20 > Jonathan > _______________________________________________ > 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