Re: [TLS] Flags extension and announcing support

Yoav Nir <> Mon, 25 January 2021 21:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03C3A3A1901 for <>; Mon, 25 Jan 2021 13:04:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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, URIBL_BLOCKED=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 Ci23W9Me3oYB for <>; Mon, 25 Jan 2021 13:04:25 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 308AF3A192E for <>; Mon, 25 Jan 2021 13:04:20 -0800 (PST)
Received: by with SMTP id hs11so20082079ejc.1 for <>; Mon, 25 Jan 2021 13:04:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hE2h2tEFNEvKEkHOm/BG+BCfaH5qSR18x0E/wVqtqYM=; b=S3feeOmEGvQ2ozCj9SIJAgW31/fOA+9HxUvgMBTnfitU+l5c1eL9j3Cs2QOyTztBBk XxW3JPq8wN4l9n/HHNCikKfijyKgTjDLoKGR3ssSSrLuvEXgJjaP4vis0rbaepbxxvKP LUZlQtIwl+M2RosImzCvqGKteX/ISW45XtLmguZk8DJBKEmthQZeZjdl2MeFZtPWFOI1 kEFrHBb6Opl1JZ9OhLULiSNp3HZk1308IbsdqITz7B68Xxl7k/Qqdp3095yf4q4GJDf6 XP6AmLNQuEHMhSJDSlA8qNLdicBgHJZfo8ypDP2Nx2K1RBaX0eaTbXPlGXEFSpn/H/0Z CyOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hE2h2tEFNEvKEkHOm/BG+BCfaH5qSR18x0E/wVqtqYM=; b=ojjUpkZenAn2/teAjxs9Hkvx4F2T/kVlKoeFBsET5JKwhUgU5xPdCutX/ae1ZWD7Mz YkgcIr/5FkhwvqAT1fMz3Z/9XAle9SAj3DmOI1iDz0/8q52NsB54quPvAammzWWddHZu wUnHOsOV9FBgXh5LntMgdKhALEBEFVyj7T3o3rFlDblUiajsxwVs+rakfvxDfse/Hc85 5/otHMQIQnTujEVwzK5doy86es+GXfSJZc4vWPxdaWXK13n0jjZn9ChVCCPb3vKLepmU cQOlEhejU9JJFyQGQ4TDpwsCjY5Zj1IAbHS4BRp+yBd6/YK2lujHPb+satASE+RoEnlZ qBzg==
X-Gm-Message-State: AOAM531R2vL5JHZCKjgAsfVz+Ju/9f2CO+QarxRxBtclUIUUkR1EEuSD YwZE2ZLPzIZTP5ImUa2+hG8=
X-Google-Smtp-Source: ABdhPJxI3/yRebXMmXYHocik6mugaCQFPjFoWb7c1tAkuZcfdwBzqtnc7ey3w5r/1mwuqF8P8RI+0A==
X-Received: by 2002:a17:906:708f:: with SMTP id b15mr1505799ejk.267.1611608658423; Mon, 25 Jan 2021 13:04:18 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id cy13sm11303514edb.27.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jan 2021 13:04:17 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Mon, 25 Jan 2021 23:04:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [TLS] Flags extension and announcing support
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: Mon, 25 Jan 2021 21:04:32 -0000

OK. I think we have as much consensus as we’re likely to get.

I’ve updated the patch branch and PR to reflect this.


> On 22 Jan 2021, at 7:45, Martin Thomson <> wrote:
> On Fri, Jan 22, 2021, at 16:16, Yoav Nir wrote:
>> See this PR:
> It looks like there is lots of disagreement there.  I'm going to disagree with others too.
>> All except the first are Server-side.
> Certificate is client-side too.
>> The controversy is about unsolicited flags. An unsolicited flag is a 
>> flag that is set in a Flags extension in a server-side message without 
>> having been first declared in the ClientHello extension.
> So I think that you need to separate requests from responses.  Because Certificate contains response to ClientHello or CertificateRequest, my view is that CertificateRequest can contain any flag (provided that the definition of that flag permits it or you don't know whether it does) and Certificate can only contain flags that CertificateRequest did.  
> This is part of what Ekr seems to have objected to, and I agree with him there.  A server should be able to use any flag in NewSessionTicket or CertificateRequest because those are the messages that initiate an exchange (NST doesn't generate any response, so it's an exchange with one flight, but that's immaterial).
> To review:
> ClientHello is answered by HelloRetryRequest, ServerHello, EncryptedExtensions, and (server) Certificate.
> CertificateRequest is answered by (client) Certificate.
> NewSessionTicket is not answered (which is totally fine).
> Those three first messages above can include new flags.  They can contain the extension or not at the discretion of the entity that sends the message.  Those messages that are in response can only contain the extension if the initiating message contained the extension.  Furthermore, the extension can only contain a specific flag if the initiating message contained that flag.
> In other words, each flag is treated just like an empty extension: you can initiate an exchange with it, but you can only answer with it if it was initiated with it.
> This differs a little from Chris who suggests that only NewSessionTicket can include a flag that was previously not indicated.
> _______________________________________________
> TLS mailing list