Return-Path: 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 ED0143A07FB for ; Tue, 7 Jul 2020 12:11:39 -0700 (PDT) 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, 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 AXaV5QnZRCQT for ; Tue, 7 Jul 2020 12:11:37 -0700 (PDT) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 D91DD3A07CA for ; Tue, 7 Jul 2020 12:11:37 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id cv18so1195095pjb.1 for ; Tue, 07 Jul 2020 12:11:37 -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=AxSEHCyku+hRfWl/qyihecqy+ApKO24ym4hGsL8IhY8=; b=aPlWccx7LQNlF1FT2bQz5FPfmUllhE+/Kw42HFwg/LVrW2SikUdMc4J/Fd86lzCRO3 oL6OtdEcMxfczfPpkWChfn2tw4hUC0d4m+KLOzfBK4UIGFbAaXB2QJ6IY0t1ToeZKbfw fH2Ka6kJ/TcO7Gg2npBZI9pGgTDZxVBcFccZ0= 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=AxSEHCyku+hRfWl/qyihecqy+ApKO24ym4hGsL8IhY8=; b=kbGrfuF0EdupTiSxXIXfIhV4Na6CsyEpjybdWr2qA43r4bJSGn6yRN6gzytc4NSA0l nLLkJI1vXbjuZcVk4Tk3Te+GFfmPxXNva5ZEogGwjjupotnkaG/PQpH+UrFD+ruhysMW 49viqecmonUkcWV+ANNP0He6DGJxmZhUQYJ8Y+QWZOOMlNazB8MPD9ZYclDDd43GWDYy WdUj6lshKE8VIdnwtKxbi2ybK63eLPDCLXXcIEtbyhBIVthfq/3KYq4eIfH4UAfV3A7M E/ksFtJ9RKYVc9o9e4E+Xu2ScCa9rA4CMOhDdS219GytUv2fwwXF16VCFmXLdslFmwS/ Gtig== X-Gm-Message-State: AOAM5334b4s0knm8rJvYWy13CTuzBIKzVcJ+HNS6+bIl4p58ijDkjRsU HtZCaCv6a7zW0qXaZ3S4g1GuUnSCMn0+0SgpuGg8SX1JqQ== X-Google-Smtp-Source: ABdhPJxEg9DqPNb8jEZMpTCglVD/haa/eMwEMsRxV31NeydCQOv1Z5Mg106ZFeTfUvZtMlA3u21v29ZvTj0kWUJne3s= X-Received: by 2002:a17:90a:aa83:: with SMTP id l3mr5755713pjq.73.1594149097000; Tue, 07 Jul 2020 12:11:37 -0700 (PDT) MIME-Version: 1.0 References: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> In-Reply-To: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> From: David Benjamin Date: Tue, 7 Jul 2020 15:11:20 -0400 Message-ID: To: Martin Thomson Cc: "" , HTTP Working Group Content-Type: multipart/alternative; boundary="000000000000a5b84605a9dec24a" Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 19:11:40 -0000 --000000000000a5b84605a9dec24a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Martin, You=E2=80=99re right that this is closely related to half-RTT data. However= , I don=E2=80=99t think this is a no-op for HTTP/2. I=E2=80=99m not aware of HTTP/2 clients that wait for the SETTINGS frame to= day. Doing so costs a round-trip with servers that don=E2=80=99t send SETTINGS i= n half-RTT, and there's no indicator for whether the server will send it. I=E2=80=99ll see about testing some sites here and will report back, but I = expect most do not. We (correctly) designed TLS 1.3 as a drop-in replacement for TLS 1.2, which means that we don't get to key new I/O patterns on it. Half-RTT data is a very weird state and wouldn=E2=80=99t get used by defaul= t. This is the problem with =E2=80=9Cno standards change is required=E2=80=9D style= of thinking around simply changing I/O patterns. A protocol is more than its wire image. Changing the I/O patterns is a protocol change. This means we cannot get efficient and reliable feature negotiation today. Moreover, HTTP/2 servers today may send ServerHello..Finished without application data in their first flight, so we need *some* change to the TLS flight, be it ALPS or just some indicator. Let=E2=80=99s look at what it=E2=80=99d take to make half-RTT SETTINGS work= . We need some =E2=80=9CI will send half-RTT data, so you can safely wait for it=E2=80=9D = indicator. Then the client needs to know when it is done waiting. We could say it=E2=80=99s= one SETTINGS frame, but that only allows integer values. (Related: EXTENDED_SETTINGS and discussion .) Those currently need separate frames, and one cannot wait for the absence of a frame. Maybe we need an HTTP-level SETTINGS_WILL_SEND_HALF_RTT_XYZ_FRAME indicator to keep the delimiter in HTTP, or a TLS-level =E2=80=9Cend of half-RTT data=E2=80=9D delimiter. (Now= consider how that works in QUIC...) Next we need to tackle 0-RTT. Waiting for half-RTT data costs a round-trip in 0-RTT, so we need something to persist across the session, with semantics around mismatch and whatnot. (Another TLS-visible change.) Anything persisted in the session must have bounded size, and be delivered in something ordered with NewSessionTicket. If we place those bytes inside the handshake, we=E2=80=99ve reinvented ALPS= . If we place them outside, the NewSessionTicket ordering becomes complex, especially in QUIC . To your question about the server repeating its configuration vs. the client remembering it, I believe the issue was exactly that ordering mishap. ALPS avoids this because EncryptedExtensions and NewSessionTicket are ordered. On top of this, the half-RTT point in a non-0-RTT connection is a weird state. Not all connection properties (e.g. client certs) have been established yet, and writes out of turn are tricky. This message discusses some of the challenges here. I would argue something like ALPS is the settings design we should have had all along. David On Tue, Jul 7, 2020 at 1:10 AM Martin Thomson wrote: > Hi Victor, > > For HTTP/2, this is essentially a noop, as endpoints are required to send > SETTINGS immediately. Whether these bytes appear before Finished or not > only affects endpoints that aren't inclined to wait for SETTINGS. This i= s > somewhat complicated by the way that TLS 1.2 and TLS 1.3 differ, but if w= e > assume TLS 1.3 here, any uncertainty is easily avoided. > > The main justification here appears to be based on the lack of 0.5-RTT > send capability at some servers. I don't know how to assess whether the > cost of greater integration with the TLS stack is preferable to fixing th= e > 0.5-RTT send problem. > > For HTTP/3, this has some incremental effect beyond that. In effect, thi= s > deliberately introduces head-of-line blocking for settings. You can > already do that in HTTP/3 if you are not prepared to deal with settings > being in an ambiguous state. There's a little more determinism here in > terms of where you look for the data that unblocks progress, but with > retransmissions, this is not a difference worth worrying about. > > What this head-of-line blocking might allow is the development of new > extensions that are unable to deal with uncertainty regarding SETTINGS. > But isn't it also possible to address that problem by saying "if you > implement extension X, then you MUST NOT send requests prior to receiving > SETTINGS?" > > In QUIC, we decided that having the server repeat its configuration after > 0-RTT was preferable to remembering it. This was after a non-trivial > number of questions about that part of the specification. You seem to ha= ve > taken the opposite approach. Is that deliberate? If so, why? > > On Tue, Jul 7, 2020, at 05:12, Victor Vasiliev wrote: > > Hello TLS and HTTP working groups, > > > > (QUIC WG bcc'd as this has been discussed there before) > > > > Currently, we use SETTINGS frames as an extensibility mechanism in > > HTTP/2 and HTTP/3. The SETTINGS frame is sent at the very beginning of > > TLS application data; this approach, while simple, has some drawbacks. > > The most notable one is that when SETTINGS are used to negotiate > > extensions, there is an entire round-trip where the client can send > > requests, but doesn't know yet about any server extensions, thus making > > any extension-dependant requests take an extra RTT. > > > > The proposed solution to this problem is to move HTTP SETTINGS frame > > into the TLS handshake. Here are some issues where this has been > > discussed before: > > * https://github.com/quicwg/base-drafts/issues/3086 > > * https://github.com/quicwg/base-drafts/issues/3622 > > * https://github.com/WICG/client-hints-infrastructure/pull/30 > > I wrote up a draft for the TLS extension that would solve this problem: > > https://tools.ietf.org/html/draft-vvv-tls-alps-00 > > > > I also wrote up a draft that explains how to use that extension with > > HTTP, and defines some settings (the ones discussed here > > ) that would not be > > possible without it: > > https://tools.ietf.org/html/draft-vvv-httpbis-alps-00 > > > > I would appreciate feedback on those drafts. > > > > Thanks, > > Victor. > > _______________________________________________ > > 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 > --000000000000a5b84605a9dec24a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,

You=E2=80=99re right that this is closel= y related to half-RTT data. However, I don=E2=80=99t think this is a no-op = for HTTP/2.

I=E2=80=99m not aware of HTTP/2 clients that wait for th= e SETTINGS frame today. Doing so costs a round-trip with servers that don= =E2=80=99t send SETTINGS in half-RTT, and there's no indicator for whet= her the server will send it. I=E2=80=99ll see about testing some sites here= and will report back, but I expect most do not. We (correctly) designed TL= S 1.3 as a drop-in replacement for TLS 1.2, which means that we don't g= et to key new I/O patterns on it. Half-RTT data is a very weird state and w= ouldn=E2=80=99t get used by default. This is the problem with =E2=80=9Cno s= tandards change is required=E2=80=9D style of thinking around simply changi= ng I/O patterns. A protocol is more than its wire image. Changing the I/O p= atterns is a protocol change.

This means we cannot get efficient and= reliable feature negotiation today. Moreover, HTTP/2 servers today may sen= d ServerHello..Finished without application data in their first flight, so = we need some change to the TLS flight, be it ALPS or just some indic= ator.

Let=E2=80=99s look at what it=E2=80=99d take to make half-RTT = SETTINGS work. We need some =E2=80=9CI will send half-RTT data, so you can = safely wait for it=E2=80=9D indicator. Then the client needs to know when i= t is done waiting. We could say it=E2=80=99s one SETTINGS frame, but that o= nly allows integer values. (Related: EXTENDED_SETTINGS and discussion.) Those currently need separate frames, and one cannot= wait for the absence of a frame. Maybe we need an HTTP-level SETTINGS_WILL= _SEND_HALF_RTT_XYZ_FRAME indicator to keep the delimiter in HTTP, or a TLS-= level =E2=80=9Cend of half-RTT data=E2=80=9D delimiter. (Now consider how t= hat works in QUIC...)

Next we need to tackle 0-RTT. Waiting for half= -RTT data costs a round-trip in 0-RTT, so we need something to persist acro= ss the session, with semantics around mismatch and whatnot. (Another TLS-vi= sible change.) Anything persisted in the session must have bounded size, an= d be delivered in something ordered with NewSessionTicket.

If we pla= ce those bytes inside the handshake, we=E2=80=99ve reinvented ALPS. If we p= lace them outside, the NewSessionTicket ordering becomes complex, especiall= y in QUIC. To your question about the server repeating its co= nfiguration vs. the client remembering it, I believe the issue was exactly = that ordering mishap. ALPS avoids this because EncryptedExtensions and NewS= essionTicket are ordered.

On top of this, the half-RTT point in a no= n-0-RTT connection is a weird state. Not all connection properties (e.g. cl= ient certs) have been established yet, and writes out of turn are tricky. <= a href=3D"https://mailarchive.ietf.org/arch/msg/tls/hymweZ66b2C8nnYyXF8cwj7= qopc/">This message=C2=A0discusses some of the challenges here. I would= argue something like ALPS is the settings design we should have had all al= ong.

David

On Tue, Jul 7, 2020 at 1:10 AM Martin Thomson <mt@lowentropy.net> wrote:
=
Hi Victor,

For HTTP/2, this is essentially a noop, as endpoints are required to send S= ETTINGS immediately.=C2=A0 Whether these bytes appear before Finished or no= t only affects endpoints that aren't inclined to wait for SETTINGS.=C2= =A0 This is somewhat complicated by the way that TLS 1.2 and TLS 1.3 differ= , but if we assume TLS 1.3 here, any uncertainty is easily avoided.

The main justification here appears to be based on the lack of 0.5-RTT send= capability at some servers.=C2=A0 I don't know how to assess whether t= he cost of greater integration with the TLS stack is preferable to fixing t= he 0.5-RTT send problem.

For HTTP/3, this has some incremental effect beyond that.=C2=A0 In effect, = this deliberately introduces head-of-line blocking for settings.=C2=A0 You = can already do that in HTTP/3 if you are not prepared to deal with settings= being in an ambiguous state.=C2=A0 There's a little more determinism h= ere in terms of where you look for the data that unblocks progress, but wit= h retransmissions, this is not a difference worth worrying about.

What this head-of-line blocking might allow is the development of new exten= sions that are unable to deal with uncertainty regarding SETTINGS.=C2=A0 Bu= t isn't it also possible to address that problem by saying "if you= implement extension X, then you MUST NOT send requests prior to receiving = SETTINGS?"

In QUIC, we decided that having the server repeat its configuration after 0= -RTT was preferable to remembering it.=C2=A0 This was after a non-trivial n= umber of questions about that part of the specification.=C2=A0 You seem to = have taken the opposite approach.=C2=A0 Is that deliberate?=C2=A0 If so, wh= y?

On Tue, Jul 7, 2020, at 05:12, Victor Vasiliev wrote:
> Hello TLS and HTTP working groups,
>
> (QUIC WG bcc'd as this has been discussed there before)
>
> Currently, we use SETTINGS frames as an extensibility mechanism in > HTTP/2 and HTTP/3. The SETTINGS frame is sent at the very beginning of=
> TLS application data; this approach, while simple, has some drawbacks.=
> The most notable one is that when SETTINGS are used to negotiate
> extensions, there is an entire round-trip where the client can send > requests, but doesn't know yet about any server extensions, thus m= aking
> any extension-dependant requests take an extra RTT.
>
> The proposed solution to this problem is to move HTTP SETTINGS frame <= br> > into the TLS handshake. Here are some issues where this has been
> discussed before:
>=C2=A0 * https://github.com/quicwg/base-drafts/= issues/3086
>=C2=A0 * https://github.com/quicwg/base-drafts/= issues/3622
>=C2=A0 * https://github.com/WICG/clie= nt-hints-infrastructure/pull/30
> I wrote up a draft for the TLS extension that would solve this problem= :
> https://tools.ietf.org/html/draft-vvv-tls-alps= -00
>
> I also wrote up a draft that explains how to use that extension with <= br> > HTTP, and defines some settings (the ones discussed here
> <https://github.com/quicwg/base-drafts/iss= ues/3622>) that would not be
> possible without it:
> https://tools.ietf.org/html/draft-vvv-htt= pbis-alps-00
>
> I would appreciate feedback on those drafts.
>
> Thanks,
>=C2=A0 Victor.
> _______________________________________________
> 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
--000000000000a5b84605a9dec24a--