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.