Re: [Masque] FW: New Version Notification for draft-kuehlewind-quic-proxy-discovery-00.txt

Patrick McManus <mcmanus@ducksong.com> Tue, 05 November 2019 21:37 UTC

Return-Path: <mcmanus@ducksong.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 E748D1208CB for <quic@ietfa.amsl.com>; Tue, 5 Nov 2019 13:37:00 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ducksong.com header.b=EqH13H3v; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=eknpRsy0
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 1wN-e-BhvegX for <quic@ietfa.amsl.com>; Tue, 5 Nov 2019 13:36:57 -0800 (PST)
Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 8D2EF120B7E for <quic@ietf.org>; Tue, 5 Nov 2019 13:36:57 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1572989816; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=D45konUt+AWNENOGClB40mekpvr/uSb6pFiE2LMFulHKdn0WiFn0lwpZMR14kz2j78cXvy7RMFy9O GvQL6m0PC+RftLr5WVrZe0+C3G74j5tR4Mle6eRsQGcs8vZJMreLqYLD0IMVwtnVT+ReNOCYbhuE/8 HjiuNBRl78PCf0tZQhwoPsB7L31vs/1nxy8e7ASi6rt6JVfM4FB99uDmIvRDIN1nRbRiZVwv/54M/X ageeIWN3YjHTPqWUnaRJVpKhVfv6IbTnqIRhUH0spaOjU2i47VR18gZlauwFDjkGl6ObOlST5AVZU+ CnoADmC1W/0t72sDXJ1b3W3QTq12l+A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=ndFPt93WfX78vT/GYP3fZ1Xedf/ZtJzu7Ke3HXfbU7w=; b=dViCp9B7VJpTWlNaN8o93hfg99YtLwVS1j1+FJBWTJx6Od/cKq8t1e6SUmEtmZMW/cXPPO4TgPAen OXmAu1WJ3P5vPMDxIO3pHEiCnxC2/wH7g+ghInmCjDGN+CYeDMEH1gIu17rRiOm6NO9yWb7LgHf+OX cf9Gjpxahgyc5KBAVBLDzt99Fxxvm3UzNIxYejrNLAtyS+T9kUHLs7W2pFWI2/UXetBlG0L3Epf3iT 10hxqYPXBP0Ds6YYyIpF20bxIblVTRQ1xBedQVD534LfKEELrSd0TN7Zyj7WPy79TraLZdL0wbjVhh oHGjMj4tz0eVEhHg3O5spGjIth5gzlw==
ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.210.46; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=ndFPt93WfX78vT/GYP3fZ1Xedf/ZtJzu7Ke3HXfbU7w=; b=EqH13H3vzjmJ9Q+bg+gbb55U+qMMxChwX9M20U63zw4Ze77ML8l4k9iH8AweWTzBS74mWmwsQGOVW ZzccmKt1NjiKd2nmPu9QZi7crMB2CcOq2LbAIvXlCjguRkBR9/w5xnRfSSeN+pyoXOrJrR1gnc7PqW HNAYavRjJySkXi1A=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=ndFPt93WfX78vT/GYP3fZ1Xedf/ZtJzu7Ke3HXfbU7w=; b=eknpRsy0XuFrJlg4ck++n08FKPNzcxia6/DzBnF4C28xYcqFfHdfTE76Oj0K0iAHIBQYP/ngRPxWy 5y23qoxMPRQmgtzXc4a6szfQl+SCHqV6Ltj6rrdedALP0iJgHcNa/7f3XpdYFQ9k2fyXxUnSI2uho4 7bEbvp1pw/P7QNBddDSjnjC+PLLn8SVFYv0CtVdrGoIE1Ps77N1jF8xSgC1eUyKOgcngD3C+LUKwWb lB4Sgrgr1pxq9xsn87ReE/FrAG4kz4MybfC18Ab43PqKAeALD0vKj0wSt9Ga1gMtpX0RGcwtLnwb4T YThrMPg7QzpkLv7fj8yGmOEMv7R4VKA==
X-MHO-RoutePath: bWNtYW51cw==
X-MHO-User: 62a1ddfe-0014-11ea-b80b-052b4a66b6b2
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Originating-IP: 209.85.210.46
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from mail-ot1-f46.google.com (unknown [209.85.210.46]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 62a1ddfe-0014-11ea-b80b-052b4a66b6b2; Tue, 05 Nov 2019 21:36:54 +0000 (UTC)
Received: by mail-ot1-f46.google.com with SMTP id l14so4653323oti.10; Tue, 05 Nov 2019 13:36:54 -0800 (PST)
X-Gm-Message-State: APjAAAVvSPLKPWCWcGe1fRykYfvpH7qttlTEVVOg4KZ9dL1V8bZfqN5h CfklE+6bmB9NcMNVrncNf8+PTOeWxZCA+Cb2ms4=
X-Google-Smtp-Source: APXvYqxIe7efKivjsrrXd/IPzAk4HInJleen+pApGKmyGa36A8GxRBjaN+fF8h2d8MiKERVwLW3bvrFtDrlM/qGTHgk=
X-Received: by 2002:a9d:6f96:: with SMTP id h22mr3388549otq.45.1572989814022; Tue, 05 Nov 2019 13:36:54 -0800 (PST)
MIME-Version: 1.0
References: <157288641719.16495.4218503379126128243.idtracker@ietfa.amsl.com> <CA5EB3C0-F510-4883-B50B-51A3E46B47CA@ericsson.com> <CALGR9obp-YARLEXDVWvTqZ_h=Ocbn6m2On+uovK-SL-6TaOSXg@mail.gmail.com> <3F20108D-DEED-4AEF-89D3-55F11058110B@ericsson.com> <CALGR9oYHce0mnkj5Kz13EoR-zN3-xSr0igkJF2Z_dJ2vgfVNSQ@mail.gmail.com> <SN6PR11MB3087D25371090E7E40FA32B2CE7F0@SN6PR11MB3087.namprd11.prod.outlook.com>
In-Reply-To: <SN6PR11MB3087D25371090E7E40FA32B2CE7F0@SN6PR11MB3087.namprd11.prod.outlook.com>
From: Patrick McManus <mcmanus@ducksong.com>
Date: Tue, 05 Nov 2019 16:36:42 -0500
X-Gmail-Original-Message-ID: <CAOdDvNruDZuBYp2ABfWCKMF4o6rY5Qk6x6ofH1qCJgLfKpsCUg@mail.gmail.com>
Message-ID: <CAOdDvNruDZuBYp2ABfWCKMF4o6rY5Qk6x6ofH1qCJgLfKpsCUg@mail.gmail.com>
Subject: Re: [Masque] FW: New Version Notification for draft-kuehlewind-quic-proxy-discovery-00.txt
To: "Su, Chi-Jiun" <Chi-Jiun.Su@hughes.com>
Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, "quic@ietf.org" <quic@ietf.org>, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>, "masque@ietf.org" <masque@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000019a84a0596a03b5b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/4rCs638UXyfVMisp7XpSNUmun2Y>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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, 05 Nov 2019 21:37:01 -0000

wpad is mostly an anti-pattern these days for important reasons - there is
no authentication. When there was less https it was chronically responsible
for people getting owned.

If the client is explicitly using a proxy it must have a reason to use and
trust a particular one (or class of one). quic of course provides
authentication to the peer and in the normal http way of things this auth
is linked to the origin which is rooted in some kind of out of band
information (i.e. the url obtained from a secure source such as an input
box, a bookmark, the command line, or transitively by finding the url
embedded in a resource found in those ways). unsecured broadcast mechanisms
like dhcp on (mostly) unauthenticated local networks don't satisfy that
which is why proxy config is generally viewed as an end host configuration
requirement that can't be autodiscovered. (often done right via enterprise
config).

even scenarios that only envision a series of CONNECT tunnels to the proxy
are giving up the end to end security of transport features that QUIC has
added and so I would think use of a untrusted proxy (i.e. one not rooted in
a trust anchor in some meaningful way) should be discouraged.

On Mon, Nov 4, 2019 at 3:35 PM Su, Chi-Jiun <Chi-Jiun.Su@hughes.com> wrote:

> Here are some more related to wpd for http:
>
>
>
> https://tools.ietf.org/html/draft-chow-httpbis-proxy-discovery-00
>
>
>
> https://tools.ietf.org/html/draft-nottingham-web-proxy-desc-01
>
>
>
>
>
>
>
> *From:* Masque <masque-bounces@ietf.org> *On Behalf Of *Lucas Pardue
> *Sent:* Monday, November 4, 2019 12:16 PM
> *To:* Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
> *Cc:* quic@ietf.org; Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>;
> masque@ietf.org
> *Subject:* Re: [Masque] FW: New Version Notification for
> draft-kuehlewind-quic-proxy-discovery-00.txt
>
>
>
> *CAUTION:* This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
> I'm not an expert in either WPAD [1] or PAC [2], but I am an expert in
> feeling their pain as a user on Windows. Part of their pain comes from lack
> of formal standardization, resulting in some word-of-mouth approaches to
> problem solving, especially how they work (or don't) with the standardised
> approaches such as DHCP.
>
>
>
> In looking this up, I did discover draft-ietf-wrec-wpad-01, a > 20 I-D for
> WPAD [3], wow!
>
>
>
> [1] - https://en.wikipedia.org/wiki/Web_Proxy_Auto-Discovery_Protocol
> <https://urldefense.com/v3/__https:/en.wikipedia.org/wiki/Web_Proxy_Auto-Discovery_Protocol__;!0rLxnc5oh4s!jPosQt26EajScgUupoiCIMKOtu1eu9R0tg2CEkMXNq8Cx56sCmkL7PmI9PN7gcAGxA$>
>
> [2] - https://en.wikipedia.org/wiki/Proxy_auto-config
> <https://urldefense.com/v3/__https:/en.wikipedia.org/wiki/Proxy_auto-config__;!0rLxnc5oh4s!jPosQt26EajScgUupoiCIMKOtu1eu9R0tg2CEkMXNq8Cx56sCmkL7PmI9POhddlmBA$>
>
> [3] - https://tools.ietf.org/html/draft-ietf-wrec-wpad-01
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-wrec-wpad-01__;!0rLxnc5oh4s!jPosQt26EajScgUupoiCIMKOtu1eu9R0tg2CEkMXNq8Cx56sCmkL7PmI9POJiXk9oA$>
>
>
>
> On Mon, Nov 4, 2019 at 5:09 PM Mirja Kuehlewind <
> mirja.kuehlewind@ericsson.com> wrote:
>
> Hi Lucas,
>
>
>
> no, we didn’t consider this yet but only because we were not really aware
> of that. Do you have a pointer? Or send a PR 😊
>
>
>
> https://github.com/mirjak/draft-kuehlewind-quic-proxy-discovery
> <https://urldefense.com/v3/__https:/github.com/mirjak/draft-kuehlewind-quic-proxy-discovery__;!0rLxnc5oh4s!jPosQt26EajScgUupoiCIMKOtu1eu9R0tg2CEkMXNq8Cx56sCmkL7PmI9PMVg31Abw$>
>
>
>
> Mirja
>
>
>
>
>
> *From: *Lucas Pardue <lucaspardue.24.7@gmail.com>
> *Date: *Monday, 4. November 2019 at 18:06
> *To: *Mirja Kuehlewind <mirja.kuehlewind@ericsson.com
> <mirja.kuehlewind@ericsson..com>>
> *Cc: *"quic@ietf.org" <quic@ietf.org>, "masque@ietf.org" <masque@ietf.org>,
> Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>
> *Subject: *Re: [Masque] FW: New Version Notification for
> draft-kuehlewind-quic-proxy-discovery-00.txt
>
>
>
> Thanks for sharing this.
>
>
>
> I wonder if you considered WPAD (Web Proxy Autodiscovery) or PAC (Proxy
> auto-config)? Although targetted at the application layer, it might help to
> comment on how those forms of discovery would relate to the methods
> outlined in your draft.
>
>
>
> Cheers,
>
> Lucas
>
>
>
> On Mon, Nov 4, 2019 at 4:58 PM Mirja Kuehlewind <mirja.kuehlewind=
> 40ericsson.com@dmarc.ietf.org> wrote:
>
> Hi all,
>
> we submitted a new draft that lists discovery mechanisms for QUIC-based
> proxies (see below). This is one piece of work that is needed for most of
> the use cases in draft-kuehlewind-quic-substrate.
>
> Let me know if you have any questions or comments!
>
> Mirja
>
>
> On 04.11.19, 17:53, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
> wrote:
>
>
>     A new version of I-D, draft-kuehlewind-quic-proxy-discovery-00.txt
>     has been successfully submitted by Mirja Kuehlewind and posted to the
>     IETF repository.
>
>     Name:               draft-kuehlewind-quic-proxy-discovery
>     Revision:   00
>     Title:              Discovery Mechanism for QUIC-based,
> Non-transparent Proxy Services
>     Document date:      2019-11-04
>     Group:              Individual Submission
>     Pages:              11
>     URL:
> https://www.ietf.org/internet-drafts/draft-kuehlewind-quic-proxy-discovery-00.txt
> <https://urldefense.com/v3/__https:/www.ietf.org/internet-drafts/draft-kuehlewind-quic-proxy-discovery-00.txt__;!0rLxnc5oh4s!jPosQt26EajScgUupoiCIMKOtu1eu9R0tg2CEkMXNq8Cx56sCmkL7PmI9PP6fOtFfw$>
>     Status:
> https://datatracker.ietf.org/doc/draft-kuehlewind-quic-proxy-discovery/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-kuehlewind-quic-proxy-discovery/__;!0rLxnc5oh4s!jPosQt26EajScgUupoiCIMKOtu1eu9R0tg2CEkMXNq8Cx56sCmkL7PmI9PNirJBnKQ$>
>     Htmlized:
> https://tools.ietf.org/html/draft-kuehlewind-quic-proxy-discovery-00
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-kuehlewind-quic-proxy-discovery-00__;!0rLxnc5oh4s!jPosQt26EajScgUupoiCIMKOtu1eu9R0tg2CEkMXNq8Cx56sCmkL7PmI9PNt2ljWVQ$>
>     Htmlized:
> https://datatracker.ietf.org/doc/html/draft-kuehlewind-quic-proxy-discovery
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-kuehlewind-quic-proxy-discovery__;!0rLxnc5oh4s!jPosQt26EajScgUupoiCIMKOtu1eu9R0tg2CEkMXNq8Cx56sCmkL7PmI9PNLkowwPw$>
>
>
>     Abstract:
>        Often an intermediate instance (such as a proxy server) is used to
>        connect to a web server or a communicating peer if a direct end-to-
>        end IP connectivity is not possible or the proxy can provide a
>        support service like, e.g., address anonymisation.  To use a non-
>        transparent proxy a client explicitly connects to it and requests
>        forwarding to the final target server.  The client either knows the
>        proxy address as preconfigured in the application or can dynamically
>        learn about available proxy services.  This document describes
>        different discovery mechanisms for non-transparent proxies that are
>        either located in the local network, e.g. home or enterprise
> network,
>        in the access network, or somewhere else on the Internet usually
>        close to the target server or even in the same network as the target
>        server.
>
>        This document assumes that the non-transparent proxy server is
>        connected via QUIC and discusses potential discovery mechanisms for
>        such a QUIC-based, non-transparent proxy.
>
>
>
>
>     Please note that it may take a couple of minutes from the time of
> submission
>     until the htmlized version and diff are available at tools.ietf.org
> <https://urldefense.com/v3/__http:/tools.ietf.org__;!0rLxnc5oh4s!jPosQt26EajScgUupoiCIMKOtu1eu9R0tg2CEkMXNq8Cx56sCmkL7PmI9PNQh7NkuA$>
> .
>
>     The IETF Secretariat
>
>
>
> --
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/masque__;!0rLxnc5oh4s!jPosQt26EajScgUupoiCIMKOtu1eu9R0tg2CEkMXNq8Cx56sCmkL7PmI9PO4I6Apdw$>
>
> --
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque
>