Application-Layer Protocol Settings
Victor Vasiliev <vasilvv@google.com> Mon, 06 July 2020 19:16 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 000B03A09D8
for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 6 Jul 2020 12:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-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, RCVD_IN_MSPIKE_H4=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001,
USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
header.d=google.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 6G_m_5OatVLK
for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>;
Mon, 6 Jul 2020 12:16:05 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18])
(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 54CBD3A09BE
for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 6 Jul 2020 12:16:04 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92)
(envelope-from <ietf-http-wg-request@listhub.w3.org>)
id 1jsWYF-0003Qr-02
for ietf-http-wg-dist@listhub.w3.org; Mon, 06 Jul 2020 19:13:15 +0000
Resent-Date: Mon, 06 Jul 2020 19:13:15 +0000
Resent-Message-Id: <E1jsWYF-0003Qr-02@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76])
by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.92)
(envelope-from <vasilvv@google.com>)
id 1jsWYE-0003QE-7Z
for ietf-http-wg@listhub.w3.org; Mon, 06 Jul 2020 19:13:14 +0000
Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b])
by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.92)
(envelope-from <vasilvv@google.com>)
id 1jsWY9-0007ZG-On
for ietf-http-wg@w3.org; Mon, 06 Jul 2020 19:13:13 +0000
Received: by mail-lj1-x22b.google.com with SMTP id d17so32097532ljl.3
for <ietf-http-wg@w3.org>; Mon, 06 Jul 2020 12:13:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=gpF5lo7bAddunoqXtCAWWG5b8eN1zv6R+OQomFo6SZ8=;
b=DgSos9Up71p445RYLMblv+4iOEeuJhxFKMqlmoz57ddQ2t2eCWSfxmtCymYm5KYoM6
SSqYYgkqwvJAEA6RacbOdUOB62eB89kD9LAHxyjJGugjwrj3ZY6CQyd6GzcwDTbM5rVB
+/nrVqMXXRLQRLrvFY1XWp9ihGxIKWTTdL0k6qnRbVcwFroZTDC50bGf3uuG6jfv/No9
EcuJ5IQwD0mTrSZzc3BNQkuJkcG0v4DKK3FQRxaa8CJr+PnfPK/CCam+KnxdESXwi7VM
fNAfDXlKQCkmaTGZlgjU6RFcS3enSGcThEMVFD9jwcXhdxd8fAXsXy2d5AI6YRn+Xg/V
DDqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=gpF5lo7bAddunoqXtCAWWG5b8eN1zv6R+OQomFo6SZ8=;
b=FNzFglpFYWAlMMPGJJuvYNxDRKPsFqPI542ET3U3ZTXhmDCns5imf+K2rdmMSqTb9S
70UvZl/u+tBOAQ+uO3u4gZrusyXwrkdAA+q2OKsEQRj+e/cxHSn5q1hvqjEjvMtayr+q
iQTCTnUih+img3+CsUrcrmY37NsY1ci6M6XKR2p4DuxkH9MHYmKu1BheAuAmxc0MBV3X
67y5YtCiGPUP5T6vvo7B3FVIRaxSGa3/Fxac1t4SUkyT0O1mZKV4r5eFXi5DiYFsBg3t
WkQ0zgLLMGf2wObrm0gVcY+dpOoC74Bclsuaoj2azPdnBuf2RUj89aNPQPh4aNfKRh5S
ZTMw==
X-Gm-Message-State: AOAM532mJfLZ8AAoBuCc0MegUwXQ665+UTlaMffGf/fB6lZaXyYOdxYS
IlJ4YZdlKMj8z5oTv9K/I/waXYsJsKJUsEjzNIDgPQ==
X-Google-Smtp-Source: ABdhPJzmPpPGvJEaorPZysEl0nwIQ1kqmPpJqgYroNEiQxaSYNfsQ+J7eIrV3ky4TLi1eSQLO65Q8e1qSGD987TjfqM=
X-Received: by 2002:a05:651c:106e:: with SMTP id y14mr1971885ljm.381.1594062776729;
Mon, 06 Jul 2020 12:12:56 -0700 (PDT)
MIME-Version: 1.0
From: Victor Vasiliev <vasilvv@google.com>
Date: Mon, 6 Jul 2020 15:12:45 -0400
Message-ID: <CAAZdMaf2dKab0dJU8MLZc9JzEcVSvf8s9kgeZFo3tmsRtx2sNQ@mail.gmail.com>
To: "tls@ietf.org" <TLS@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000008f08ac05a9caa908"
Received-SPF: pass client-ip=2a00:1450:4864:20::22b; envelope-from=vasilvv@google.com; helo=mail-lj1-x22b.google.com
X-W3C-Hub-Spam-Status: No, score=-24.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1jsWY9-0007ZG-On acb64531772b2cb2be2b3b251077c09e
X-Original-To: ietf-http-wg@w3.org
Subject: Application-Layer Protocol Settings
Archived-At: <https://www.w3.org/mid/CAAZdMaf2dKab0dJU8MLZc9JzEcVSvf8s9kgeZFo3tmsRtx2sNQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37841
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>
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 <https://github.com/quicwg/base-drafts/issues/3622>) 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.
- Application-Layer Protocol Settings Victor Vasiliev
- Re: [TLS] Application-Layer Protocol Settings Ben Schwartz
- Re: [TLS] Application-Layer Protocol Settings Martin Thomson
- Re: [TLS] Application-Layer Protocol Settings Ilari Liusvaara
- Re: [TLS] Application-Layer Protocol Settings David Benjamin
- Re: [TLS] Application-Layer Protocol Settings David Benjamin
- Re: [TLS] Application-Layer Protocol Settings Ben Schwartz
- Re: [TLS] Application-Layer Protocol Settings David Benjamin
- Re: [TLS] Application-Layer Protocol Settings Martin Thomson
- Re: [TLS] Application-Layer Protocol Settings Victor Vasiliev
- Re: [TLS] Application-Layer Protocol Settings Martin Thomson
- Re: [TLS] Application-Layer Protocol Settings Lucas Pardue
- Re: [TLS] Application-Layer Protocol Settings Victor Vasiliev
- Re: [TLS] Application-Layer Protocol Settings David Benjamin
- Re: [TLS] Application-Layer Protocol Settings Lucas Pardue
- Re: [TLS] Application-Layer Protocol Settings David Benjamin
- Re: [TLS] Application-Layer Protocol Settings Lucas Pardue
- Re: [TLS] Application-Layer Protocol Settings David Benjamin
- Re: [TLS] Application-Layer Protocol Settings Victor Vasiliev
- Re: [TLS] Application-Layer Protocol Settings David Benjamin
- Re: [TLS] Application-Layer Protocol Settings Lucas Pardue