Re: Questions on HTTP URI schemes and QUIC

Ted Hardie <> Tue, 24 July 2018 16:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DFA5130F3B for <>; Tue, 24 Jul 2018 09:08:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FBrhuUtwbBy8 for <>; Tue, 24 Jul 2018 09:08:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 26B05131156 for <>; Tue, 24 Jul 2018 09:08:25 -0700 (PDT)
Received: by with SMTP id k12-v6so8447699oiw.8 for <>; Tue, 24 Jul 2018 09:08:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M9pBVUPsSjXpo31w58FtVDjFxll6ybZhF0YzAHEV340=; b=H0HsJ0zrTdqnaAybokqnB4hFV8EPHKLntRfK0bx9DzQad8bwj44WQmVV1P40lXoJBe MTDulgXxPCxwCOhjlyoIM/1ev/ougP3ooJz8P+Mo0lay0zJ4TCJpTBV23gF5twftYca4 yd9z88pXSLFVbL51MYqfYdwgYR+VBa8B+94FkmbCW7wwN+QQCV+4ccQQqZn5oNvfRCBn ENIvAoUlTFJHXKNwT1BAklbFReWMP1WmdJWX6ECMzvo1JOYKQOAAdDLTwXVAfTK5egBS 5WLCMQjQboqTXnkKjhrXutYA3Am5p1DhifutAzt6IttbzoIUbPqhUpdb2AwnwP/RYbgf ZC2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M9pBVUPsSjXpo31w58FtVDjFxll6ybZhF0YzAHEV340=; b=rs6iR6YDYjUrrFNc6ERHxcx6TXYyHAdCkdSin8KIIuMoE8UuYmCa1MhtMbZHFlfaE1 jZi5whZ5H3OTrWBnHCtcWjikG1BzZLrg8L+gZOyv0KCcS26357ZhunGB+UVKUyJoi7VZ KTTyEyLFSf16Q42q06VzYFUzsDqMoQ/KKtKEWnVyxjJoKUTzLs3wVxo24evCkVEDRtca WygX9TrhA/mHeGQOYdGQR39nnZM7Lp64MQozIQ3GO8P6kBQlY6gt7TZluJJ5ihJ37II1 3x78PBVUgP+t4SIt9eS9MnxSVArG497sokPDaCW3/wRl9eNUEK+U8n4k7FB6Ei6zhDzY iEjw==
X-Gm-Message-State: AOUpUlEdsN1eZzkCzE4bOQbvqtSSU7xJpIFGxWKg1oFLxNWArfn8k3ia LzKUt7tYo2J2wbOatCMEosRp4KoWNFF9nXCwiC4=
X-Google-Smtp-Source: AAOMgpcY/a1AkLSUfp52EUvJSYVH3aZ9734/N33yeL7mDsmCE/+LAzneWYJeHtQE6RpqQ8a9IBBb4Q+ae5MtZJRWy+Y=
X-Received: by 2002:aca:d015:: with SMTP id h21-v6mr4084831oig.142.1532448504173; Tue, 24 Jul 2018 09:08:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Tue, 24 Jul 2018 09:07:53 -0700 (PDT)
In-Reply-To: <>
References: <> <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012> <> <7CF7F94CB496BF4FAB1676F375F9666A3BB786A5@bgb01xud1012> <>
From: Ted Hardie <>
Date: Tue, 24 Jul 2018 09:07:53 -0700
Message-ID: <>
Subject: Re: Questions on HTTP URI schemes and QUIC
To: Sridhar Bhaskaran <>
Cc: Lucas Pardue <>, IETF QUIC WG <>
Content-Type: multipart/alternative; boundary="000000000000ba58420571c0f81c"
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: Tue, 24 Jul 2018 16:08:27 -0000

Hi Sridhar,

On Mon, Jul 23, 2018 at 8:36 PM, Sridhar Bhaskaran <> wrote:

> Yes this is understood. One follow up question is - can a bump in TLS (TLS
> interception) where a proxy provides certificates on behalf of origin host
> signed by its own CA (provided the client is configured to trust this CA)
> work with QUIC? Can this be made to work to intercept the protected payload
> at a proxy?
> Thanks
> Sridhar

Before going down that road, may I ask why 3gpp prefers the
bump-in-the-wire style proxy, rather than a configured proxy?  A configured
proxy can act as a back-to-back user agent, which allows the kind of
inspection you describe.  The  mechanism can also be set to work either on
a per-network basis or globally (depending on the configuration and the
topology).  Is that not a better fit for your deployment model?