Re: Questions on HTTP URI schemes and QUIC

Patrick McManus <> Wed, 18 July 2018 13:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E6211311C7 for <>; Wed, 18 Jul 2018 06:38:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.233
X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DGHGPbfHCeTl for <>; Wed, 18 Jul 2018 06:38:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5079F1311B0 for <>; Wed, 18 Jul 2018 06:38:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id CAEC73A028 for <>; Wed, 18 Jul 2018 09:38:12 -0400 (EDT)
Received: by with SMTP id w126-v6so8801175oie.7 for <>; Wed, 18 Jul 2018 06:38:12 -0700 (PDT)
X-Gm-Message-State: AOUpUlHUoX9oB3dUkqXYfKVc6Vxwc7Lg74FplfZLnzFrJCJrYhHyTVhe DzavbUiYmzTXXXV4QxTgrZQP7QzTdP6NBkX5/wU=
X-Google-Smtp-Source: AAOMgpdPgOHeRUhre+9EJEQ23UFxg4QxV+5sZAXg+ab9XyIk5KymatFEWndyjQ0uCz0p/3uG1J2kCzm+MDj3qwfq3GY=
X-Received: by 2002:aca:a806:: with SMTP id r6-v6mr6772681oie.213.1531921092545; Wed, 18 Jul 2018 06:38:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 06:38:11 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Patrick McManus <>
Date: Wed, 18 Jul 2018 09:38:11 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
Subject: Re: Questions on HTTP URI schemes and QUIC
To: Sridhar Bhaskaran <>
Content-Type: multipart/alternative; boundary="0000000000008ba1130571462c73"
Archived-At: <>
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Jul 2018 13:38:25 -0000

On Wed, Jul 18, 2018 at 6:49 AM, Sridhar Bhaskaran <> wrote:

> Dear Quic experts,
> I am Sridhar Bhaskaran from Huawei. Going through the drafts on QUIC
> transport and HTTP over QUIC, I have the following queries
> 1. If a HTTP URI uses http:// scheme and the origin server advertises
> alternate service via QUIC, can a HTTP client use QUIC to connect to the
> origin server and still use the http:// scheme URI?

There is an experimental RFC, 8164, that would probably apply here for
consenting endpoints. 8164 requires the same crypto and authentication as
https - so you should probably just go with https unless you're already
using that strategy with h2 for legacy mixed content.

> 2. If a HTTP URI uses https:// scheme and the HTTP client is configured
> to connect to a HTTP proxy and if the HTTP proxy supports QUIC, my
> understanding is the following sequence of events
>         a. HTTP client to HTTP proxy QUIC connection is setup
>         b. HTTP client issues a HTTP CONNECT request to the proxy with the
> ":authority" HTTP/2 pseudo header pointing to the origin server
>         c. HTTP proxy upon getting the CONNECT request sets up a TCP
> connection with the origin server
>         d. HTTP proxy sends HTTP CONNECT response to the client
>         e. HTTP client then initiates a TLS connection towards the origin
> server via the proxy and the proxy simply tunnels it.
>         f. Actual HTTP traffic happens between client and origin server
> Is this correct?
i believe so

> Where I am not clear is whether step /e/ actually happens. If it does,
> then for step /f/ is the client required to do ciphering 2 times - one for
> the TLS and other for the QUIC connection to proxy itself.
yes, connect tunnels are end to end encryption for their content so the
data that flows between the client and proxy is encrypted twice. That's the
same in all versions of http.

Could you please clarify?
> Thanks
> Sridhar