Re: [TLS] TLS Flags Open Question

Sean Turner <sean@sn3rd.com> Tue, 05 January 2021 03:07 UTC

Return-Path: <sean@sn3rd.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 5FDC63A0DC0 for <tls@ietfa.amsl.com>; Mon, 4 Jan 2021 19:07:59 -0800 (PST)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qjtte02wa8IS for <tls@ietfa.amsl.com>; Mon, 4 Jan 2021 19:07:57 -0800 (PST)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6995E3A0D9A for <tls@ietf.org>; Mon, 4 Jan 2021 19:07:57 -0800 (PST)
Received: by mail-qt1-x82a.google.com with SMTP id g24so20014770qtq.12 for <tls@ietf.org>; Mon, 04 Jan 2021 19:07:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=MPrqLDFgRVkF3UOBO4299PNODdt6hblNghjKUcop4k8=; b=ipS7tdnFfizk7+/4KbNOsxLWYAX+t2kn/e9ZFO21pc3RtAD6AinX86L1AFRt0IFONj NbGQRkJSEOwl5OsrlK6bNJ/ZzZWtyJGbrY83vYNfxqbnrH7VuPk9UDis/+h2lJZsOJii 9Ue8/bymnxoxlfANQQ9JGwfJACKUYQsj0gqHE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=MPrqLDFgRVkF3UOBO4299PNODdt6hblNghjKUcop4k8=; b=PSPlJpTww9S7yZqHTticSMPQoKnmR+SOf/TVb+MdG6Bh7uUAnvhsN/tH6rNFpGf2yr CCpAJJoMQ7wWNeRaje12C8HNig87QTaj1S1WW0ZcVhMfO3edYya/KgGJQ9yIq/JPS/3K 0w/RIz7ClgVU7ksDJ/RmfmvdV5tD6jTm7LJ6gnnAqIluWUODnqpK1WPkTZieHRXd6M3A xT2XaNwTkKhJcErVXHY3NXBWmHUHNW3cT/RYFoQNNPs/Qc1wU1CI/KkHXiB4QAZEZtLs RIUc9FeLmrtRo1JQZFv+2/1Cu2wCfiHL1rAQyerniWovMzWtfbMJlM2Ji+QC8h78qrww qtow==
X-Gm-Message-State: AOAM531mt5q1rwQ3Obs842YvF3CZpSYUeaF8+lhX1NKgHG7NNbHXkQPF tMwDPSX6ZlHA8PABWOukuCb23g==
X-Google-Smtp-Source: ABdhPJx0ePbtU8gDwHnd19rHMO18wMoCYlZzIl/HAUN9LtqHtEG3O7KtK9O5SzoxEFmm2xd5WbVuaw==
X-Received: by 2002:ac8:74c7:: with SMTP id j7mr73088765qtr.102.1609816076175; Mon, 04 Jan 2021 19:07:56 -0800 (PST)
Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id n66sm38521434qkn.136.2021.01.04.19.07.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Jan 2021 19:07:55 -0800 (PST)
From: Sean Turner <sean@sn3rd.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Mon, 4 Jan 2021 22:07:54 -0500
References: <D83A814D-F420-47A2-8F80-BD68988F97F8@gmail.com> <18ACC957-3D46-436E-AB11-69861FC6870C@gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>, TLS List <tls@ietf.org>
In-Reply-To: <18ACC957-3D46-436E-AB11-69861FC6870C@gmail.com>
Message-Id: <3D10ADC8-669B-42C1-A7A9-26530F9F97EE@sn3rd.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qNQzsIwL-ZdkUWbgrivY5k-1yNA>
Subject: Re: [TLS] TLS Flags Open Question
X-BeenThere: tls@ietf.org
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." <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: Tue, 05 Jan 2021 03:07:59 -0000

Yoav,

Thanks for pulling together this PR (https://github.com/tlswg/tls-flags/pull/5). There’s already some comments in the PR. If anybody has comments please jump in. Note that this is the last outstanding issue and we would like to close this in order to progress the I-D.

spt

> On Jan 1, 2021, at 16:36, Yoav Nir <ynir.ietf@gmail.com> wrote:
> 
> As all (OK, both) of the responses have been supportive, I have created a pull request:
> 
> https://github.com/tlswg/tls-flags/pull/5
> 
> Yoav
> 
>> On 5 Dec 2020, at 17:04, Yoav Nir <ynir.ietf@gmail.com> 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
>> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls