Re: [TLS] Can flags be responded to with an extension?

Yoav Nir <ynir.ietf@gmail.com> Mon, 09 May 2022 15:10 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 ADDB9C15E419 for <tls@ietfa.amsl.com>; Mon, 9 May 2022 08:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 AI6TcwAiZPKc for <tls@ietfa.amsl.com>; Mon, 9 May 2022 08:10:48 -0700 (PDT)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 4BE0BC159A1F for <tls@ietf.org>; Mon, 9 May 2022 08:10:48 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id 129so8564314wmz.0 for <tls@ietf.org>; Mon, 09 May 2022 08:10:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=60uaph0sZFLL8PcYwWjH4VxvBFE0OUzUBOU0NW6Qk0I=; b=itR/+wGD/+EIuPJstLMPxBeK2KmhGhO2mvcDhNNESpi4HxypzJcmvfHwQAbOS3boAT zU/XKFphG4TEKhP1rlnxWkCUPg6f/i2Eu4ZdVuqubXrwLFnBG3v1SCmeSs833lRQzeGv IP0EFi5YleY+VrYCvXrfKA0peg4+1ROUW50Svd0Wv/MCj++H0WexKMZ0LkLTwIPqQS4q j7liZuY8R5l+dACuLR/THufccv1i7vwSxf4Qq6IWgJSOf9PnJRT0JejHcBI2Nfm8bFh4 zDwn8oSVwvbG8Fj1AjiV59lo5QOFzArpDp6IjJWFitLMxMJEyXClN7NttRmGEoYBv6/0 XIzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=60uaph0sZFLL8PcYwWjH4VxvBFE0OUzUBOU0NW6Qk0I=; b=C6himvwIW4mue/3bpCT1h3o1ZbwzEwtpWJ+CC7oasRnf0bXLVyYfgEUZPQ+0IYNoxo n30qx4ApPcZQLAOYpSImvPDMV9+xcJfpUKrzwit0MRAe2EoxnlNvM0QsTXlqP4YYwnaB Orrg0YZbToS+njpcrNyJtA/RW/jPgHLKJ1OaNJiaiXMtAuluysBP+ioeRenEeDBKu3fH ObUtqGBV6qQfuFId0rSrHr7wGm1TWyAKuCjGH6+Eylfhv4H3v4HJB+mA8f++/KOX8r2v /oBwznlZaB56Uj3yu+XZZ5qFL/j0YzPtsedWGkQibME4J253e57i5WrORmLXAZwyo7oX I03Q==
X-Gm-Message-State: AOAM532ai41DZybNT8IWvb2hH1FxHqS2D3YbD3ghGzQKDBrvdL7kupak x1EG5omWaNR3UF51kozffmN87wUHXGt/tA==
X-Google-Smtp-Source: ABdhPJzN7Z/b1qo0ulW+bR7F8NA3S29zIHvQElQCvDUX+RVXx8nU7u47naiWaQDMyUe1UggHCBgAnA==
X-Received: by 2002:a7b:c081:0:b0:394:789b:915 with SMTP id r1-20020a7bc081000000b00394789b0915mr16003569wmh.105.1652109046179; Mon, 09 May 2022 08:10: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 r13-20020a056000014d00b0020c5253d91esm11517777wrx.106.2022.05.09.08.10.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 May 2022 08:10:45 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <20220413225130.GC3149@akamai.com>
Date: Mon, 09 May 2022 18:10:43 +0300
Cc: Eric Rescorla <ekr@rtfm.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <00386759-28C6-4E54-BC9C-1C566D4A0B6D@gmail.com>
References: <CABcZeBPyqFSgdiUbgKk5QbHnDA_zT8RH_KROebTrUNOnfqZZGQ@mail.gmail.com> <20220413225130.GC3149@akamai.com>
To: Benjamin Kaduk <bkaduk=40akamai.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/rkGAbmSOXUEx0psEyMZsKVfT7Ls>
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, 09 May 2022 15:10:48 -0000


> 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?

Yoav