Re: [TLS] WGLC for "A Flags Extension for TLS 1.3"
Yoav Nir <ynir.ietf@gmail.com> Tue, 21 April 2020 19:31 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 1DBCB3A0898 for <tls@ietfa.amsl.com>; Tue, 21 Apr 2020 12:31:52 -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 zAcfm3xxZWDM for <tls@ietfa.amsl.com>; Tue, 21 Apr 2020 12:31:49 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 71DEB3A0884 for <tls@ietf.org>; Tue, 21 Apr 2020 12:31:48 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id g13so15883497wrb.8 for <tls@ietf.org>; Tue, 21 Apr 2020 12:31:48 -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=IHlznP0Sa8GQINUcm8hJrRt5HwsKLtOWbfhLf8KIx4k=; b=mShwddo54uLqwzHwfG2K1OmBVR/qMapWrfXwa11C9Ayk6g6VO1wU0dR4/f3+lxDBAo Cn2YX8VaugayR3oaJzW0rTCnspoGdK5+Le5HSe0F5BODkVTfMgY/MktvPhC/TFmhppc6 vAnjVnON5RDk2ZrUE+7kGkELFrxSM2LeseAaLaloDzf0zOcCUqO/TxdZswTgSP3nGyRY m6vqyNGv8qOTe5bBkHSIlkKMGf0OPmQcgKcIhCT7Wuo3/SirYWpg/bJzaRyFNvkRRmNE jAKZn5HW+13UNn3xBAeg+bv0J+WGHTWh4UGI2TBDFbEjvY86/D5GeToQhF11za2zA/UI H8Xg==
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=IHlznP0Sa8GQINUcm8hJrRt5HwsKLtOWbfhLf8KIx4k=; b=biqp6AncLddgw6X4j3JxY1/J7BqzLApfInD0qvl0i1QHZMYCCC1rLTRm2yR6H2rUt8 1cNixDZw9cGYC9/O58tqOEayu55ROzjNXl+lggxjTiE9VtyelKYVt16rCuqsw8lNUz36 d5q209LOewRjGUSlaQbni7Tia/URD3V2RNIuCf8bFa795f+t881EvRcoenQCR0q4T11a mfSx+tgaROLKbYQU07XAreFtOCIRuV1lFXmIo5Z5O3U3Q1rRHS+CYGuFDY7RfXipGAUi rvjNi6ruB4t72prmRlYusAv1jpDXxFVSC/8N+1niSq55E3oXL1Oa4NgPguUGTkBUdaaG O6Gw==
X-Gm-Message-State: AGi0PuainD9oMigBm4Fb6raNLCO0/tfPSRWrAfbd38NwKcBdj625oIiN wJFHxrR9S7LI7mkuySmNgQ0OMDKZ
X-Google-Smtp-Source: APiQypIY9Epq7w58jPJQZSZaSqoBTcANzAj4TIWcLNqLML2YGWNk8iHQO0jxHdKDswLTMqw45+dTpw==
X-Received: by 2002:adf:fe41:: with SMTP id m1mr25239299wrs.52.1587497504519; Tue, 21 Apr 2020 12:31:44 -0700 (PDT)
Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id n7sm4642833wmd.11.2020.04.21.12.31.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2020 12:31:43 -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: <3aab08b9-d979-4952-85f6-62e993f6fb4b@www.fastmail.com>
Date: Tue, 21 Apr 2020 22:31:41 +0300
Cc: tls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B6EC2F38-504C-46C0-B5A3-F16ED27CA923@gmail.com>
References: <bf0f823a-99ab-46b0-9b2a-d397d6bf3139@www.fastmail.com> <3aab08b9-d979-4952-85f6-62e993f6fb4b@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/MtzHwZpMoTAZfYTp-kmaykL-XRc>
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: Tue, 21 Apr 2020 19:31:53 -0000
Inline... > On 7 Apr 2020, at 1:39, Martin Thomson <mt@lowentropy.net> wrote: > > I like this work, but I don't believe this to be ready yet. > > S1 > None of the current proposed extensions are such that the server > indicates support without the client first indicating support. So as > not to preclude future extensions that are so defined, this > specification allows the client to send an empty extension, > indicating support for TLS flags in general (and presumably some > unspecified features in particular). > > First, for clarification, the distinction between empty and all-zero-valued is perhaps worth drawing on. I think the description of the extension in section 2 is clear. An extension without any flags set is empty, It’s not all zero-valued. A FlagsExtensions field with a length of 1 and the one byte being zero is an invalid encoding of the extension as its length is the minimal length possible. So only an empty extension is meaningful. > Second, more seriously, if this is the goal, the text needs to acknowledge that the possibility exists on a *per-flag* basis. Can you suggest text? > > 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. > Fourth, this conflicts with the following text in S2: > > A server that supports this extension and also supports at least one > of the flag-type features that use this extension and that were > declared by the ClientHello extension SHALL send this extension with > the intersection of the flags it supports with the flags declared by > the client. Agree. So either we abolish “silent client - server declares” extensions (let’s call them unsolicited), or we rephrase the above something along the lines of: A server that supports the extension and also supports at least one flag that was either present in the ClientHello extension or is allowed to be sent unsolicited, SHALL send this extension with all of the flags it is configured to support except those that are not allowed to be sent unsolicited and that were not present in the ClientHello extension > Nit here: this isn't about support alone, it is the flags that the server *chooses* to support. “configured to support” ? > S2 > The server may need to send two tls_flags extensions, > one in the ServerHello and the other in the EncryptedExtensions > message. > > 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) I think this requires another field in the IANA registry. 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. > Perhaps we might avoid this problem entirely. ServerHello extensions are limited to key exchange. If we say that flags are limited (today) to functional properties that don't affect key exchange, my thought is that we don't lose much (if anything) by only allowing this extension in EncryptedExtensions. 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? > I don't know what I think about Certificate extensions. This seems to have a clear use there. > > Editorial: > > S1 > It might be better to draw examples from the canon of published RFCs than to refer to things that might not get published. I support I cna mention RI earlier. > > On Tue, Apr 7, 2020, at 00:53, Christopher Wood wrote: >> This is the working group last call for the "A Flags Extension for TLS >> 1.3" draft, available at: >> >> https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ >> >> Please review the document and send your comments to the list by April >> 20, 2020. The GitHub repository for this draft is available at: >> >> https://github.com/tlswg/tls-flags >> >> Thanks, >> Chris, on behalf of the chairs >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
- [TLS] WGLC for "A Flags Extension for TLS 1.3" Christopher Wood
- Re: [TLS] WGLC for "A Flags Extension for TLS 1.3" Salz, Rich
- Re: [TLS] WGLC for "A Flags Extension for TLS 1.3" Martin Thomson
- Re: [TLS] WGLC for "A Flags Extension for TLS 1.3" Christopher Wood
- Re: [TLS] WGLC for "A Flags Extension for TLS 1.3" Yoav Nir
- Re: [TLS] WGLC for "A Flags Extension for TLS 1.3" Martin Thomson
- Re: [TLS] WGLC for "A Flags Extension for TLS 1.3" Yoav Nir
- Re: [TLS] WGLC for "A Flags Extension for TLS 1.3" Christopher Wood