Re: [TLS] Flags extension and announcing support

Sean Turner <> Thu, 28 January 2021 16:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D00003A161D for <>; Thu, 28 Jan 2021 08:13:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iPhiB1uWI79j for <>; Thu, 28 Jan 2021 08:13:47 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E39BA3A162F for <>; Thu, 28 Jan 2021 08:13:46 -0800 (PST)
Received: by with SMTP id v3so4441835qtw.4 for <>; Thu, 28 Jan 2021 08:13:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SDBbU6yHoVxRvIdGY3StuP3cxwJKNLVPdoQCU4FHChc=; b=SZJ7h1KnQWly/ULkrD+aO0Pf5vf9UQH38xNmmme/prCvynaKvcUiRpKkZgMjXB+3gv adw6of425fvF4aG2A4D9/10+SxbbLObedxI2ruYk9aAvfxGuTqz9oyJTh0CKpsP5npjB 3OHPVInL3ECEImV1vBHI32Qj8DOK+V3pTzFMY=
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=SDBbU6yHoVxRvIdGY3StuP3cxwJKNLVPdoQCU4FHChc=; b=aVrGMJeklxW2eanhBWmpVRDkgPrTyJbD5HigPAco+j5tiM4zcitAP53a6C8oCvsBdH PcC3durt84GzxmNlXQBdjssVuZ8BLNoSLxH7Sq5nToXc9f0mc8m4Z//zGNsvqW5UN40k L3+86A5gLcbA/xGrCeQz0ATCIRKeM3pTuhKBowdN46OOF1eNchV3BzpGMy3bUBjLzGVD KBo90YAcdBr8wIS2t3aJTxGtO2i3eVTY9QP+/PsdE6gNiDA4g4L3hk47oldFGutP5qep uEhG14JrIm9u87sbSZr4hLi9dShmmAbS0+DidZYXkk2N9x8VnreR8yC8L2FMDqliRrPT JLpA==
X-Gm-Message-State: AOAM531FCbMfBkiFvug5yTpMPgf+JTt1+iXBjvZn/jg3+6aHjMv7os6K dRWSbHH19CxPQUXLvWYA/gR9Kg==
X-Google-Smtp-Source: ABdhPJw0gK33OW7NzJ/UYNf1ur22fk4A3NR442msa+SXwTyjWQ54Esir2Vg3tbEA4pE2zHkfreZoIg==
X-Received: by 2002:ac8:8ca:: with SMTP id y10mr227323qth.330.1611850425902; Thu, 28 Jan 2021 08:13:45 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id d26sm3506533qtw.58.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Jan 2021 08:13:44 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Sean Turner <>
In-Reply-To: <>
Date: Thu, 28 Jan 2021 11:13:42 -0500
Cc: Martin Thomson <>, TLS List <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Yoav Nir <>
X-Mailer: Apple Mail (2.3608.
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: Thu, 28 Jan 2021 16:13:54 -0000


I think that’s right, i.e., update the patch branch and PR.


> On Jan 25, 2021, at 16:04, Yoav Nir <> wrote:
> 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.
> Yoav
>> 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
> _______________________________________________
> TLS mailing list