Re: [TLS] TLS Flags Open Question

David Benjamin <davidben@chromium.org> Mon, 07 December 2020 16:16 UTC

Return-Path: <davidben@google.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 CA3743A15C2 for <tls@ietfa.amsl.com>; Mon, 7 Dec 2020 08:16:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.25
X-Spam-Level:
X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 cweQfC8huTOh for <tls@ietfa.amsl.com>; Mon, 7 Dec 2020 08:16:25 -0800 (PST)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 0AAF73A1422 for <tls@ietf.org>; Mon, 7 Dec 2020 08:16:20 -0800 (PST)
Received: by mail-pj1-x102d.google.com with SMTP id e5so7620197pjt.0 for <tls@ietf.org>; Mon, 07 Dec 2020 08:16:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MTts1gj/fY3SDxuk9apKwKAAlREzPSNGK+PvXwPL8Bs=; b=hMCOud5unX5ByTjFUuk0ds3pUoXvj2pIKcLppTAJkXHiw7QzpqFVs11CKCajbK9Oiv tUrT/uTUTk7wW2cM0UyyxIRPcj80kMi6VQn5WTm5pAStHYVgCksffbGhYTw1BDCsKqgh 0pmFiJGMbsS03xghoYt1cWGOiDVRK7n+nxaqE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MTts1gj/fY3SDxuk9apKwKAAlREzPSNGK+PvXwPL8Bs=; b=lK9lDVlqWijsgvMmQpPpcqFUvdr6VVV5uKlKLrrlkBJT3y+7SSfxCKvt63Id2SZYid v9b2FqXc/XndUiaEyxVlHALhGDye7UPp4yLOe/VttyS257WQX8u1DLBfm3Q57Wg07orC 9Ja0kuPo+sk8lOjDW2Yf7N0g4hhcD/YPQgjs9tzo6cSF+6ePRw0XYqtE62q9i0VPEyPP kf5jfdqfGTYsExVzar9ghVDQEWxWUkxZ8ojCA+FdAvTpYEwQ7WQwxxxmCTAmHNleEYqH nvww2uULUxza9cXihbz2yp5z8oCYkq42ZJ3nevQMZSyKq79yJOnKsAU/i1eAa+9snCRo s3qA==
X-Gm-Message-State: AOAM533TkXMFSkPv1utb0qw8EkOtx1aJ65BhG0bEY7IA1NnfAhIYvdwU FP7Q+kpHQNFpoiSZMHPcdeIltbQNsZfxUjfD7bCQ
X-Google-Smtp-Source: ABdhPJwwloNt7ZXHVquPYm8ktAMZ5KXrm30fxKqpfpSGdnUl88lXSQcx+ohVzqruQZEkUAHNipbjRRdRN9oYxddnJ4o=
X-Received: by 2002:a17:90a:6346:: with SMTP id v6mr17244169pjs.162.1607357779308; Mon, 07 Dec 2020 08:16:19 -0800 (PST)
MIME-Version: 1.0
References: <D83A814D-F420-47A2-8F80-BD68988F97F8@gmail.com> <CABcZeBNF1JcWQGtL=D+=yTx8fAqxqisfs4nZxChrTj6SSpikng@mail.gmail.com>
In-Reply-To: <CABcZeBNF1JcWQGtL=D+=yTx8fAqxqisfs4nZxChrTj6SSpikng@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Mon, 7 Dec 2020 11:16:02 -0500
Message-ID: <CAF8qwaAfjUJvMg-upDP335CTd3ebNvq4Y-QXYTfF39VO1oip8w@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Yoav Nir <ynir.ietf@gmail.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000076dfc005b5e2252c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-CxCmCAONGtXq4ythxaM6B7-dQ4>
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: Mon, 07 Dec 2020 16:16:27 -0000

On Sat, Dec 5, 2020 at 6:31 PM Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Sat, Dec 5, 2020 at 7:05 AM 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.
>>
>
Should CertificateRequest be in that list? By the way, the text for section
3 might need tweaking. The rules for request vs. response extensions are
almost client/server, but not quite. Probably better to cite or adapt the
text in RFC8446, section 4.2.


> 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.
>>
>
> I agree with you that this is the right outcome.
>

I also agree.

I suspect it doesn't hugely matter since ServerHello carries response
messages. Until and unless we define a ServerHello flags extension, the no
unsolicited extensions rule and the no empty flags rule mean ServerHello
flags are effectively prohibited unless the client implements such an
extension. So that means we can punt to TLS-flags RFC. (Whereas I think
we'll need to sort out CertificateRequest now to avoid compat issues.) But
it's easy to allow it now, and saves us having to think about whether it's
safe to do later.

David