Re: [TLS] TLS Flags Open Question

Yoav Nir <> Fri, 01 January 2021 21:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F9073A0D00 for <>; Fri, 1 Jan 2021 13:36:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GmMyHTvtMPjE for <>; Fri, 1 Jan 2021 13:36:22 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A19803A0CFF for <>; Fri, 1 Jan 2021 13:36:22 -0800 (PST)
Received: by with SMTP id y24so20996275edt.10 for <>; Fri, 01 Jan 2021 13:36:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=0yZQY0O25GLYYkkqfWu4KxzqxCXg73IWw4y2MV+vcks=; b=j46jJPNVCX5ID2wl7w7s2tPn9AxxbPT/0gpBr6gvz5XO2cQoDzCY+THLG0WDsOEBGw pPfWd+8ihO0YPKo3708qCHp5leJdsUT1Kjf7MzfTGEpEBkZ5Ueb+XncVToPPubuh/bWa MMPYEIdU+u4fHZ4K9FsdcFLCZn1wFfg4IbX1QT4irG16SGoL+jVKwrUyqpCQbk/0B4+v QWl684Q29Ebk1h6ikVjQFhhwi8PaxFXfxqqeeEcVuG/8RV/desrfNaEZTMvoxnU/iRJp 94VBH594suDIV6pqEkUflflKbjQx5uQNyararikRyCgAGw6Jj6TpX7SDjGV/4ZrQqrDv Fbkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=0yZQY0O25GLYYkkqfWu4KxzqxCXg73IWw4y2MV+vcks=; b=mGvTS5u3hOR3vvED8Sapm4g4A/XcLdvyYO4cLGJs6BEUFp3dwbGbUYuII7Ow5FNzDs MPIq2S1+ORkQA3x/ounrOIx8+Ux+qXpywXC8WsbSFwQ4qvCVE2GbUm8plO9uLHJ7jr0z CqCu8aWHN9cNtyt/Qug4Dy+CYsJRgwUB3srBJ2NlENbwekQfmvSkBMvjkTUFPYjh6gGr Qwbmw6tiDfVbSypB9mnl/yNV6923NpYEF8AA9Um4jD+RwPB3WBb4kPgtzbA9dDJp/aQX JdkeGdUzNlbruhmR24B8sktltG2bZ/bP8MCooTs0yjFhf5eBvD48p5DTZP7/JuP9zWtJ LL5Q==
X-Gm-Message-State: AOAM533Bs20LQxY7zFUN3fECg3ZschEQW7k+4whFtVpZ5El7wcLeOuKO ZWjM/b7jAkutKKRGl1OlmS4Wc/OGXFvuGQ==
X-Google-Smtp-Source: ABdhPJxyaYJPtovGAhS0tluv5YpEcYwBc+fAhJrKhTYbJESNDFPOEwQMvrn4QGnlxdWTW4QvOApA0A==
X-Received: by 2002:a50:fd88:: with SMTP id o8mr61153749edt.386.1609536979524; Fri, 01 Jan 2021 13:36:19 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id ci20sm21177095ejc.26.2021. for <> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jan 2021 13:36:18 -0800 (PST)
From: Yoav Nir <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2E4CCBED-E36E-4EF1-91F5-D6DA2309B377"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Fri, 1 Jan 2021 23:36:17 +0200
References: <>
To: "<>" <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [TLS] TLS Flags Open Question
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Jan 2021 21:36:24 -0000

As all (OK, both) of the responses have been supportive, I have created a pull request: <>


> On 5 Dec 2020, at 17:04, Yoav Nir <> wrote:
> Hi.
> At IETF 108 a question was raised about The TLS Flags extension.  What  payloads on the server side can include this extension?
> The “candidates” are ServerHello, EncryptedExtensions, Certificate, and NewSessionTicket.
> The only one that is controversial here (I think) is ServerHello, because it is not encrypted.  Looking at the current list of extensions, I see that only 6 can go in ServerHello:
> password_salt
> tls_cert_with_extern_psk
> supported_ekt_ciphers
> pre_shared_key
> supported_versions
> key_share
> Of those, only one would be (if it hadn’t already been standardized) a candidate for the TLS-Flags extension: tls_cert_with_extern_psk.  The RFC describes it with “The “tls_cert_with_extern_psk" extension is essentially a flag to use the external PSK in the key schedule”.  I don’t think it’s unreasonable to think that at some point there’s going to be another flag-like extension that will need to be signalled in ServerHello.
> So the question for the group is, do we allow the flags extension (and the flags themselves) to be in ServerHello, or do we prohibit them for now, and if ever an extension does need to signal in ServerHello, it can update the TLS-Flags RFC at that time?
> My vote would be to allow it in all places, and trust the process not to place flags that should be encrypted in payloads that aren’t, but either way, we need working group consensus.
> Thanks
> Yoav