Re: Working Group Last Call: draft-ietf-httpbis-http2-tls13-00

David Benjamin <davidben@chromium.org> Fri, 06 September 2019 17:45 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980E8120145 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 6 Sep 2019 10:45:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 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, MAILING_LIST_MULTI=-1, 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=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 FCu9hANStdoo for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 6 Sep 2019 10:45:37 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AFFC120816 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 6 Sep 2019 10:45:32 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1i6IFY-0000kK-1C for ietf-http-wg-dist@listhub.w3.org; Fri, 06 Sep 2019 17:42:20 +0000
Resent-Date: Fri, 06 Sep 2019 17:42:20 +0000
Resent-Message-Id: <E1i6IFY-0000kK-1C@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <davidben@google.com>) id 1i6IFS-0000jZ-HD for ietf-http-wg@listhub.w3.org; Fri, 06 Sep 2019 17:42:14 +0000
Received: from mail-pf1-x42e.google.com ([2607:f8b0:4864:20::42e]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <davidben@google.com>) id 1i6IFQ-0004ix-V2 for ietf-http-wg@w3.org; Fri, 06 Sep 2019 17:42:14 +0000
Received: by mail-pf1-x42e.google.com with SMTP id q10so4978072pfl.0 for <ietf-http-wg@w3.org>; Fri, 06 Sep 2019 10:41:52 -0700 (PDT)
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=2ljR9e5eq/M5cLrOhAnwkUTGj2ezHqnsnDx5n03b26o=; b=nfHEWX5Mq8NunPB0N2oI5dJXI+cYvL8culIabrNecpuL2d4VqVhMNAVtQwrZnGP8Aj 6Wiay6jhIhDuDEF7y5twPrQTiG9HGGp4u32QZYPyKa9Uqc6Av5XpAa8583jZgEKuA4TU S3XGrjxk/oKXS/XMmVhQFcV7erutXo4btZETk=
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=2ljR9e5eq/M5cLrOhAnwkUTGj2ezHqnsnDx5n03b26o=; b=HMBG9d4MyDkuHpUkMYrzxRFyCInU6iNZp7vd1eh85oTiX1YKj4D9k3R9n9/Dw5ENRu FxQjyU5TJEdOQOupie79AHXQYylH+FdKKQhRd4oDPwnrx4C1/ivrFDF0AXYg8Sjj+Pr+ UVSh0xBPh5MujBAY7onbv6IL4a33mdEwHPAQsiDLgIwoS0c2iatPCBmpVk3EZHAwqHPy RehiITQIg78yA1rjqT+Mx6XYSBGitpuaSu4ueWqiaId+ucNocgnYx/axRhl4OLoc+i/G kMhTwmu+G/iG4S0uDBsjC2zWH+Fp4CFyLljXI3TAlM6FFIXLEk67diCq/b1Nd5xU9auY U75A==
X-Gm-Message-State: APjAAAWGWa+Tecmk/UjQnBmchd2Z8v5Syb6+Vjc9BfI30P2RJTeMnebi LcxLgrGIIji2kqkxz0yqQl04oe78cDPSWPsc82Rc8FFxVw==
X-Google-Smtp-Source: APXvYqxOOQdPuyREjGURFn7U5ABM2fvLyTgu5geFka7kIzfYX/sV93EL8OqP/7JmYM0X5Xzh714kdMRXZUz6fcK3XmE=
X-Received: by 2002:a63:7b4d:: with SMTP id k13mr8807665pgn.182.1567791710913; Fri, 06 Sep 2019 10:41:50 -0700 (PDT)
MIME-Version: 1.0
References: <36F559DD-7E4D-47FE-ADBF-423D09FE5AA9@mnot.net> <9cadc50c-4e5a-434b-90a2-dbcb71720567@www.fastmail.com>
In-Reply-To: <9cadc50c-4e5a-434b-90a2-dbcb71720567@www.fastmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Fri, 06 Sep 2019 10:41:34 -0700
Message-ID: <CAF8qwaD1KM=n+AHsAJTaQi+xCZatwO8mQ5UrJTQYQcyQhWCoyA@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000000337fa0591e5f49b"
Received-SPF: pass client-ip=2607:f8b0:4864:20::42e; envelope-from=davidben@google.com; helo=mail-pf1-x42e.google.com
X-W3C-Hub-Spam-Status: No, score=-11.2
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, 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, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1i6IFQ-0004ix-V2 4159de579b77569f3b088f98aae5b772
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Working Group Last Call: draft-ietf-httpbis-http2-tls13-00
Archived-At: <https://www.w3.org/mid/CAF8qwaD1KM=n+AHsAJTaQi+xCZatwO8mQ5UrJTQYQcyQhWCoyA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37005
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

My original thinking was that post-handshake auth and KeyUpdate are
relevant because they are spiritual successors of renegotiation in TLS 1.3.
The original RFC7540 targets renegotiation, so we should say something
about how the prohibition applies. For random other features, there isn't
anything existing text targeting them. But saying things more clearly never
hurts, so your replacement text SGTM too.

I do think TLS should be a bit clearer on when a feature is intended to be
transparent and behind the TLS "API" and what is meant to "caller-visible".
Features in the latter bucket like post-handshake auth and early data tend
to be rather messy and ought to be gated by an application profile,
otherwise we run into problems like these.

On Wed, Sep 4, 2019 at 8:51 PM Martin Thomson <mt@lowentropy.net> wrote:

> LGTM.  With a possible suggestion.
>
> Having just re-reviewed this concise and well-written document, and in
> tripping over the KeyUpdate piece, I think that we should have more general
> language about post-handshake messaging in TLS.  Anything that is strictly
> TLS-specific shouldn't be prohibited by this, but it somewhat implies
> that.  For instance, the heatbeat extension should be permitted.
>
> Maybe replace the language about KeyUpdate and instead say something like:
>
> ```
> 4.  Other Post-Handshake TLS Messages in HTTP/2
>
>    Section 9.2.1 of [RFC7540] does not extend to TLS 1.3 messages that are
> exchanged after the handshake is complete.  This includes KeyUpdate
> messages, which only affect TLS itself and do not require any interaction
> with the application protocol.  HTTP/2 implementations MUST support key
> updates when TLS 1.3 is negotiated.
>
>    Unless the use of a new type of TLS message depends on an interaction
> with the application layer protocol, that TLS message can be sent after the
> handshake completes.
>
>    NewSessionTicket messages are explicitly permitted.  Though these
> interact with HTTP when early data is enabled, these interactions are well
> defined in RFC 8470 and allowed for in the design of HTTP/2.
> ```
>
> I realize that this is a change, but I want to ensure that the TLS working
> group doesn't have to come back and update this document if they decide to
> add some messaging that only affects the operation of TLS.
>
> Cheers,
> Martin
>
> On Thu, Sep 5, 2019, at 13:15, Mark Nottingham wrote:
> > David indicates that he thinks we're ready for WGLC on this document:
> >
> >  https://tools.ietf.org/html/draft-ietf-httpbis-http2-tls13-00
> >
> > Please have a look through and bring up any issues here or on the
> > issues list, and please indicate support (or lack thereof) for
> > advancement on the mailing list. If you are implementing or intend to
> > implement the specification, that would be useful information for us.
> >
> > WGLC will end on 19 September.
> >
> > Cheers,
> >
> > --
> > Mark Nottingham   https://www.mnot.net/
> >
> >
> >
>
>