IETF Logo Mail Archive

Re: Questions on HTTP URI schemes and QUIC

Ted Hardie <ted.ietf@gmail.com> Tue, 24 July 2018 16:08 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFA5130F3B for <quic@ietfa.amsl.com>; Tue, 24 Jul 2018 09:08:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 FBrhuUtwbBy8 for <quic@ietfa.amsl.com>; Tue, 24 Jul 2018 09:08:25 -0700 (PDT)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 26B05131156 for <quic@ietf.org>; Tue, 24 Jul 2018 09:08:25 -0700 (PDT)
Received: by mail-oi0-x22d.google.com with SMTP id k12-v6so8447699oiw.8 for <quic@ietf.org>; Tue, 24 Jul 2018 09:08:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <0E42DD26875E1748992B1E3F732A36AE0129E9E9@BLREML503-MBX.china.huawei.com>
References: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129C45B@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB786A5@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129E9E9@BLREML503-MBX.china.huawei.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Tue, 24 Jul 2018 09:07:53 -0700
Message-ID: <CA+9kkMAZqQviCshp8opYD4OBtG+SrXJ7TeXvwMzne_xDa4-_QA@mail.gmail.com>
Subject: Re: Questions on HTTP URI schemes and QUIC
To: Sridhar Bhaskaran <sridhar.bhaskaran@huawei.com>
Cc: Lucas Pardue <Lucas.Pardue@bbc.co.uk>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ba58420571c0f81c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/L7hsb_-DfFLO38FDc1wA5tadVtM>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=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 <
sridhar.bhaskaran@huawei.com> 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?

regards,

Ted

v2.23.0 | Report a Bug | By Email