Re: [TLS] WGLC for "A Flags Extension for TLS 1.3"

Yoav Nir <ynir.ietf@gmail.com> Sat, 25 April 2020 18:38 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 465973A12E6 for <tls@ietfa.amsl.com>; Sat, 25 Apr 2020 11:38:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqPJeXhngtKb for <tls@ietfa.amsl.com>; Sat, 25 Apr 2020 11:38:27 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 2B1E73A12E5 for <tls@ietf.org>; Sat, 25 Apr 2020 11:38:27 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id t14so15547016wrw.12 for <tls@ietf.org>; Sat, 25 Apr 2020 11:38:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VsgKz21Azac5gDGD+SpVbwcg6I65QVKnR5jdIM1BmI4=; b=Odpj+iHOrwGJu6111c/6X31bSmG+LYx1SHFPMwdV5hPlp04yqWPzpeYzOkoanYC5za WulFOxVwixQjvbHP7pU8LHCQ/NA0CsKN2qzV2X/QCz4fVnKPR56fhmXGGdAUWjF6Po8g iJNahJ7c6IKowWdKPm8ZaAb9/iIqGNcpbHbw9avySyhL7935b0iE/PFQTPhOMAV/UDcU aYXA9gZ+aJ6EAbOXWR+g4d3oqxb4JoP19IOfBLHy3ngmy7INTNfetGT7IMSg00q4NRGn kIhT3IUyOHTdV4LKFrsG0LYEuEeYszrRwCpYrDtJInzsciZUXzf5VAV/HEFXtDr1NYTP MlMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VsgKz21Azac5gDGD+SpVbwcg6I65QVKnR5jdIM1BmI4=; b=P4yAz7RbpP1SiGzr0lgt4pT0w8Vu+d1mBWJJpHQSm2S5A7bTN9cR2u3KMH2+FhMSIQ HwUdYRl2TEnfSDP/Szvb66nH8/xFuspCMeoB+x1a6Lh1mO0QyP2+uqikWW/ZvCMhnANO rOwKh1s+iDQpd+c6q/K5DxXo8gzixtLTOdq80IpuqG5qPwSxNQpR3T6aHr8Wv5uHupWj 3yPhM3oAXR2sig3jX7wUBPVyYuFHUIt5uPRhQfiQxP7tfHxo5wLOIvMMnsVt8kO/FKNE DBLKKl3ORZ9oPTRdXPav5sMo8SOwqFhz4uC3lYMFx9cclX2QqK/tlnkqTIcN+VSbTnl9 EWOg==
X-Gm-Message-State: AGi0Pua8925fDYU5PULq+eWAzuoCDviIsEgd/O3/KGG6kmd7lDI26vIH gKeLaPPhhBPDAqaTP1ioyF2cgCkJ
X-Google-Smtp-Source: APiQypIalN+3hgHM4tZU2zQ4nZrTNGAJFIct9FOwhbJKfaCVBoKqOKhd2xx9Vy/5wW9ZDqqgC1p92w==
X-Received: by 2002:a5d:4dcd:: with SMTP id f13mr17787137wru.417.1587839905551; Sat, 25 Apr 2020 11:38:25 -0700 (PDT)
Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id n9sm13644683wrx.61.2020.04.25.11.38.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Apr 2020 11:38:24 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <fbc76c60-a250-40dc-95bc-7390937206aa@www.fastmail.com>
Date: Sat, 25 Apr 2020 21:38:23 +0300
Cc: tls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <730DE2CB-BD16-47B9-9729-B8D49615AB7B@gmail.com>
References: <bf0f823a-99ab-46b0-9b2a-d397d6bf3139@www.fastmail.com> <3aab08b9-d979-4952-85f6-62e993f6fb4b@www.fastmail.com> <B6EC2F38-504C-46C0-B5A3-F16ED27CA923@gmail.com> <fbc76c60-a250-40dc-95bc-7390937206aa@www.fastmail.com>
To: Martin Thomson <mt@lowentropy.net>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3kYhWlaEY4_K8b5wUmudYpgdY9A>
Subject: Re: [TLS] WGLC for "A Flags Extension for TLS 1.3"
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: Sat, 25 Apr 2020 18:38:29 -0000

See below.

I think the next thing to do is to get a signal from the working group about whether we do or don’t want to allow unsolicited server flags, because prohibiting it will require a significant change in the draft.

I’m happy to make such a change, because I still can’t come up with such a flag.

> On 23 Apr 2020, at 3:07, Martin Thomson <mt@lowentropy.net> wrote:
> 
> On Wed, Apr 22, 2020, at 05:31, Yoav Nir wrote:
>>> Third, more substantially, and invalidating the above, I don't think that we should make flags introduce a new style of negotiation just because it can.  I would strongly prefer that this function as close as possible to "empty ClientHello extension; empty EncryptedExtensions extension".  Aside from that, the utility of an advertisement from the server that a client cannot respond to is pretty marginal.
>> 
>> If this is what the group prefers, I’m fine with it, but then there’s 
>> never any point in sending an empty extension, either from the client 
>> of form the server. The absence of an individual flag is always implied 
>> from the absence of the extension.
> 
> When you say "empty extension" here, do you mean "empty flags extension" or are you speaking more generally?
> 
> If the server can't add flags, then I agree that having the client send an empty flags extension has little value.  Same for the server sending an empty flags extension in that case.

I mean the flags extension. An empty extension conveys just that the sender supports the extension. An empty CH flags extension just says the client supports the flags extension. Unless the server is allowed to send unsolicited flags, an empty flags extension in CH does not convey any useful information.
> 
>>> Are we confident that sending the same extension in both places is safe?  I know that clients have to implement this and so should be able to test that this works, but it seems awkward.  And it might not be necessary.  It's also not sufficient, as we currently allow responses to ClientHello extensions to appear in Certificate (and for CertificateRequest to carry "requests" in the other direction).
>> 
>> I don’t think the two extensions ever carry the same flags. Each server 
>> side flag should be one of three: serverHello, encrpytedExtensions, or 
>> neither (if we are not expecting a response)
> 
> So the intersection of flags in different responses must be zero?  i.e. flags[ServerHello] & flags[EncryptedExtensions] == 0 (and the same for any combination that we allow, including Certificate and NewSessionTicket, I guess).

I can’t think of any flag that will have a different meaning when sent in SH or EE so that you might want to send both. Just in case, the flag registry should have a field similar to the extension registry which says where the field is valid.

> 
>> As for Certificate, I don’t see why we’d need to add bit responses to 
>> Certificate. They can safely be sent in either serverHello or 
>> encryptedExtensions.
> 
> The obvious thing here is when the extension applies on a per-certificate basis as opposed to the entire chain.  But I don't have an example you can use; see below.
> 
>> I’m trying to come up with key exchange bits that might be useful.  
>> Perhaps a new, improved alternative to HKDF?  Support for Quantum Key 
>> Exchange?
> 
> This might require an understanding of the overall strategy.  If the goal is to provide an analogue of a generic "empty extension", then sure, put it in ServerHello.  But put it in Certificate and NewSessionTicket too.  But if you make this more narrowly applicable and say that you have a different flags extension for each type of exchange (ClientHello -> ServerHello, ClientHello -> EncryptedExtensions, ClientHello -> NewSessionTicket, ClientHello/CertificateRequest -> Certificate), then you might avoid answering this question for now.
> 
> Right now, it seems like the obvious use here is for EncryptedExtensions, so we could decide to defer that architectural question by saying that it is limited to EncryptedExtensions for now.  Then we can either expand the one flags extensions to allow it in NewSessionTicket when we need to, or define a new one.