Re: [TLS] Can flags be responded to with an extension?
Yoav Nir <ynir.ietf@gmail.com> Mon, 23 May 2022 18:27 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 9E386C19E86F for <tls@ietfa.amsl.com>; Mon, 23 May 2022 11:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_BLOCKED=0.001, 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjrEbSJWf9RG for <tls@ietfa.amsl.com>; Mon, 23 May 2022 11:27:48 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 38AF5C19E870 for <tls@ietf.org>; Mon, 23 May 2022 11:27:48 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id o9so1639253wmd.0 for <tls@ietf.org>; Mon, 23 May 2022 11:27:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nhJCOL2/ulOx3xK+D/OYuwHH5uuWOdH/Jdrb3cfTlSE=; b=OeegPZpFPulyNhjt4conGbj6bs3PMuaAhgsK1SLYTWN1EgoNwtL2aLeBr83j9DnXx4 42ACp680h3FIamR30Y5EG8SfsxDBSUj0cURu78v/r+rjN3nfxT1Tf9P0kqGs+M7kelSP tB5HN8Vrh37z/IrqtlXMHtjMZ9rMdog4vb/TO9z5RI7NZ5yJLMDHKoQBo0HEK1ytPrLf nm6cS9pb2jT5XCruHSpa/gRSJM7XKzVxTY5UXq/M90e4lnjf0zpS2EP24Ji+Ocw163VG V7igtkuDnx4loAZO5X1VEZ4/joE7gkx4LMSPB6FkUjAlfAkNqYsn7eQKjGnY4477IIwF 7yxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=nhJCOL2/ulOx3xK+D/OYuwHH5uuWOdH/Jdrb3cfTlSE=; b=BDpPcNuLQtS6An004r7Jz4TG+2nUJMDw8GoK99vTJKZMAB+CMA2J98LZuuf5iRVB+W SS34VTn4AeyVKYqdVNwQ6s1G4fdHienbebNH+iCys87JjPmXAm1WpYKzzJPMe/JSAz8q e44fgp7JROJZY3AFSLNCiywdYj3uiVz//somMHEXmuYL6/nrD5umYHjKf/FayUZWguw8 +of75ExaYQZDfWRSatdcCAn7uYsVORqcdVoXdPLnC2isgotyguBkCAQxlEn0wq+C5XIw 54w8y5vShi7J0Y7L59n5aALeVR+A2b32Zy+IS9vSttALg6LwxoL0MAUOnE1CCokmOcAI RKOw==
X-Gm-Message-State: AOAM532qrtV/QbwZlvOQeGP/Bh4MvR9o2XPx8noYWPm2duO3HiGKKpQq i9oiEqoEtWFsjJTGua0h7tvjYob1Ag3ILw==
X-Google-Smtp-Source: ABdhPJwZ/kztWh1v0KSALN5ao8Naz4AQKqn3FxKBvTuTxo9w76fTyVbngAYP5JYbPAhPuqpaq38rVw==
X-Received: by 2002:a05:600c:4e51:b0:394:9910:95ab with SMTP id e17-20020a05600c4e5100b00394991095abmr284895wmq.83.1653330466007; Mon, 23 May 2022 11:27:46 -0700 (PDT)
Received: from smtpclient.apple (84.94.37.215.cable.012.net.il. [84.94.37.215]) by smtp.gmail.com with ESMTPSA id r3-20020a7bc083000000b003974d0d981dsm2846035wmh.35.2022.05.23.11.27.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 May 2022 11:27:45 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <2A13947F-F326-4CD7-9307-4C5587C0717B@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2F389274-CA7D-4711-A893-33019BB1AF98"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Date: Mon, 23 May 2022 21:27:43 +0300
In-Reply-To: <20220509162112.GD12383@akamai.com>
To: "<tls@ietf.org>" <tls@ietf.org>
References: <CABcZeBPyqFSgdiUbgKk5QbHnDA_zT8RH_KROebTrUNOnfqZZGQ@mail.gmail.com> <20220413225130.GC3149@akamai.com> <00386759-28C6-4E54-BC9C-1C566D4A0B6D@gmail.com> <20220509154319.GC12383@akamai.com> <CABcZeBMmNfEM_uUP7cjA-3eYVp+Wkz6jzuSraNJ=Ua3ov_tVpg@mail.gmail.com> <20220509162112.GD12383@akamai.com>
X-Mailer: Apple Mail (2.3696.100.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/0qYnFvdJ8YIp3QE5xARImatmDK4>
Subject: Re: [TLS] Can flags be responded to with an extension?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.34
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: Mon, 23 May 2022 18:27:52 -0000
Hi. Here’s a PR to codify that an extension with content is NOT a proper response to a flag. I’m not merging this for now. It’s proposed text to gauge WG consensus. Yoav https://github.com/tlswg/tls-flags/pull/22 <https://github.com/tlswg/tls-flags/pull/22> > On 9 May 2022, at 19:21, Benjamin Kaduk <bkaduk@akamai.com> wrote: > > Hi Ekr, > > On Mon, May 09, 2022 at 08:56:26AM -0700, Eric Rescorla wrote: >> On Mon, May 9, 2022 at 8:43 AM Benjamin Kaduk <bkaduk= >> 40akamai.com@dmarc.ietf.org> wrote: >> >>> On Mon, May 09, 2022 at 06:10:43PM +0300, Yoav Nir wrote: >>>> >>>> >>>>> On 14 Apr 2022, at 1:51, Benjamin Kaduk <bkaduk= >>> 40akamai.com@dmarc.ietf.org> wrote: >>>>> >>>>> On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote: >>>>>> Consider the case where the client wants to offer some capability that >>>>>> the server then responds to with real data, rather than just an >>>>>> acknowledgement. >>>>>> >>>>>> For instance, supposing the SCT extension from RFC 6962 did not exist, >>>>>> the client would want to indicate support in CH and the server would >>>>>> send the SCT in CERT, but this extension would need to be non-empty >>>>>> and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit >>>>>> uncelar on this point (unless I'm missing it) but I think we >>>>>> should explicitly allow it. >>>>> >>>>> In my head this was already disallowed. I couldn't swear to whether >>>>> we actually talked about it previously or not, though. >>>> >>>> I’m pretty sure we haven’t discussed this (or at least, I wasn’t in the >>> room). In my head it’s also disallowed. In the text, it’s not explicitly >>> disallowed, but the text does talk about response flags that are in flag >>> extensions, not about responses that are in other extensions or other >>> messages. So implicitly disallowed? >>> >>> I think the description in the abstract of the target class of extension as >>> those "that carry no interesting information except the 1-bit indication >>> that a >>> certain optional feature is supported" also implicitly disallows response >>> bodies. >>> >> >> Hmm... I don't think this is really the right approach at this stage. >> >> The situation here is that the explicit text is ambiguous. If this were >> already an RFC, we would need to try to determine what it meant so that we >> could agree how implementations ought to be behaving. In that case, yes, we >> would look at this kind of language to attempt to resolve the ambiguity. >> >> However, this is not an RFC and so our task is to make the specification as >> unambiguous as possible. At this stage, we should be asking what the >> *right* answer is, not what the one that most closely matches the current >> ambiguous text. My argument is that the right answer is the one that most > > Yes. You've convinced me that we need to be (more) explicit one way or the other. > > Please treat my remark as a contribution to enumerating places in the document > that would need to change if we were to allow responses outside of the flags > extension. > > -Ben > >> closely embodies the broader goal of saving bandwidth for low-information >> signals, in this case the signal that the client could process a given >> server extension. So, yes, the client's extension contains no interesting >> information but the server's does, which, I think, is consistent with this >> text, even if, arguably, it's not the better reading. >> >> I can certainly see arguments against forbidding this practice for >> technical reasons (e.g., simplicity), but, again, then the specification >> should just say so. >> >> -Ekr
- [TLS] Can flags be responded to with an extension? Eric Rescorla
- Re: [TLS] Can flags be responded to with an exten… Ilari Liusvaara
- Re: [TLS] Can flags be responded to with an exten… Benjamin Kaduk
- Re: [TLS] Can flags be responded to with an exten… Eric Rescorla
- Re: [TLS] Can flags be responded to with an exten… Yoav Nir
- Re: [TLS] Can flags be responded to with an exten… Eric Rescorla
- Re: [TLS] Can flags be responded to with an exten… Benjamin Kaduk
- Re: [TLS] Can flags be responded to with an exten… Eric Rescorla
- Re: [TLS] Can flags be responded to with an exten… Benjamin Kaduk
- Re: [TLS] Can flags be responded to with an exten… Yoav Nir