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

Mirja Kuehlewind <> Wed, 22 January 2020 13:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34EA11200E9; Wed, 22 Jan 2020 05:54:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w0aI-hHhDXsO; Wed, 22 Jan 2020 05:54:25 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF88A120059; Wed, 22 Jan 2020 05:54:24 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=MhjTLfwJ5Frf46I2Pq5xWqN588Xlg5I3QMq8UEQpCQ6+2dG192B9LtJbMc8LZW8HP6pKNzQqxd5x7uUSbVz8vzbYdsWl2PF0xg+gt9tjt1YN/TgqkUkkHKTwXKwA0PCGYE1FsEeUBUuFFa+jiSeoMy0i+W5krtdDOlsNCSgs186TpURQZPw4MJCd0oLPjggFZsiZE3ri5Q7nyDnpE3UMEt/jWwQMjJT67D+YkogODctb4Wc0ztPdIFc69sXe4xv46rvBfZlyICYgdk1y0/Jd5DDY1+A6uN6Mq1+EUc7UJQrOapl/KWsIrbmsAHLablZdXqgPyd/axJuW8hK0T+Z7Qw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SewAk3wUHtGjF08z1P8YoFzWZXL0kCUVhx0BPZiARS8=; b=AGl4iHb01JttMLDmLLLVJw33eCzEKAVKV8z19asIZ8HNrRCjmJ1n8p9b54/E4lJJA8BAYzbVL6e+DJLnakRF8Zyaneh3+xRhXVN1dv/GoZbnlBx/iRiE2NnEZfKyTe0wOFEHwUvXUS7B9vHuUvGpPLvFQHq1cpIGaT/FnPgXFOXL3Iaz+T2jPTZdVVtp0jfJ4QCgAu2t6jiwzYQtfbp6GBVhprhAdcGkH1f2DJIs0UpupuKvcjgbcMjnKnJ+PjjS5lW8GL+XHPab478QBBLQIXJSEQg/LtLYxrPX6IOrfQ+V7/GzX0MWMSfV+TC0FxbBVWTKyxlgFMLuY9j73OXtog==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SewAk3wUHtGjF08z1P8YoFzWZXL0kCUVhx0BPZiARS8=; b=SIVji1vpwQyjGK/YBrIJJ2uu+9htTZEsxgD7UxkBcOSruLNfbiKQY8qAftp8Mov5WCNXfQIlpWeXGW5hB4GDNJ2TgriqiMrb7XPfDkckNFTXioy/w6f4bcYZD95qqJ31KjUk3wLahpR8oFMhoRlvMGTNwCrfqFO98YW8yb9XA0o=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.14; Wed, 22 Jan 2020 13:54:21 +0000
Received: from ([fe80::4879:46ae:16e:f5b7]) by ([fe80::4879:46ae:16e:f5b7%7]) with mapi id 15.20.2686.008; Wed, 22 Jan 2020 13:54:21 +0000
From: Mirja Kuehlewind <>
To: Patrick McManus <>, Lucas Pardue <>
CC: "" <>, "" <>, Zaheduzzaman Sarker <>, "Su, Chi-Jiun" <>
Thread-Topic: [Masque] FW: New Version Notification for draft-kuehlewind-quic-proxy-discovery-00.txt
Date: Wed, 22 Jan 2020 13:54:21 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-GB
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:16b8:2c2b:3f00:2d80:4c54:1d95:3831]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9402d6c3-76e1-487c-ee79-08d79f429565
x-ms-traffictypediagnostic: AM0PR07MB5283:|AM0PR07MB5283:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 029097202E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(346002)(396003)(376002)(136003)(189003)(199004)(186003)(66556008)(64756008)(66574012)(33656002)(66446008)(86362001)(4326008)(5660300002)(71200400001)(66946007)(2616005)(66476007)(44832011)(15650500001)(76116006)(6486002)(110136005)(54906003)(36756003)(8936002)(478600001)(966005)(2906002)(6506007)(81156014)(81166006)(53546011)(316002)(6512007)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5283;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: XKPFvk1b61wf9JfHS8ZAXCsFvDca62/CzJk/Ix75WCCLihtEZ2Z/M+px+U4BAQonNCBIQRSqDFw9ALy2OC8QrmihGn2W8EBsq2Ne/S49ax/1YsyuwkcCX00anwD5cCwBL35DTLzqwLDJ4iYOCZK4kuPruvv4Br4DUYy84IndBVMfvE4HpizJ2AMCGn5UMLrKutGI7txvq3/v0ZBtyggXTHFyb9tMJ3VJmFJsVa9gQ8hydIDvEAwT6SrDDLGOtaKpP7vbtyCXGuRkm6BDjYQ3sNij0qnUWv9EzxnU7oRuNzvmiC4mW2e5A6UXjp8gsiVFPousJafQqyfAMNQEF2Un5c9l4N3djk+0UqgjgcxTyruywwSsLQfaR/zvN0TYExNLaQ4AERUzZxBHel5wrcEbehSjjkpuo59j1zwJoFmfsGvcoRzJkFsUVXgysCqFq52H2THqnou43hr8JcCb3qNRKylGsRq9ll2r6tyB1PEVdvs=
x-ms-exchange-antispam-messagedata: w+Ty9tIzp1lBU9FY4CEl84bJpz0Snn8tQsJmh9arDJzxIc6UeT4QW5+deo2f2d+AtEjvEjbpMdXp1tcvtSJIlVFXppPVwSNyMKZwNbK3PJXoS/Gn1xV3lo0CYYSbV9fZBH2hM40pnCAoB5hz5me0sevBnbJBSu+LIf6qYyqce2um7SKxyp8E7/3n8cyaCndJLOxe6mh76w3X/71pfuB8DA==
Content-Type: multipart/alternative; boundary="_000_65CD80F211BF4D48A01117F6E431D209ericssoncom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9402d6c3-76e1-487c-ee79-08d79f429565
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2020 13:54:21.8108 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ak931Y1icPQe3c3tOj5H27nNsMJw8pXeqq7QvNojvBypSX3kMUJ4rqGFQWGDdDE61RZB/ZWEn8WDgFjY1IhhyFlcsNLNQE6hJ/g6sIqrUnA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5283
Archived-At: <>
Subject: Re: [Masque] FW: New Version Notification for draft-kuehlewind-quic-proxy-discovery-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiplexed Application Substrate over QUIC Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Jan 2020 13:54:31 -0000

Hi Partick, hi Lucus, hi all,

I’m currently updating the discovery draft and therefore looking at this email thread.

So looking at WPAD, it also uses DHCP and/or DNS to get a config file. In the draft we mentioned also the use of Provisioning Domains (PvDs) to get information about local configuration. This seems to be the more appropriate and soon to be standardized alternative, so I don’t think mentioning WPAD will add much. Lucas?

Mentioning WPAD could maybe lead to a discussion about who this information can be access by an application/browser (if needed because it could also be the OS that handles the proxying transparently for the app), however, this seems a bit out of scope for this document and probably is mostly covered by taps for PvDs.

Patrick, you said below that “series of CONNECT tunnels to the proxy are giving up the end to end security of transport features that QUIC“. In the setup we have in mind for use with MASQUE, we never touch the encrypted QUIC end-to-end connection and just forward those packets. Other than for HTTP/TCP proxies, the idea is to always have an outer QUIC connection between the client and the proxy and an inner QUIC connection between the client and the server. So I think if you only look for a forwarding service (+ address translation/anonymization), it’s actually okay to rely on potentially unauthenticated local discovery as you basically only have to trust the proxy as much as you trust any router on the path. However, given there is a QUIC connection between the client and the server which includes authentication, you may even be able to authenticate a known proxy even if the discovery was not authenticated.


From: Masque <> on behalf of Patrick McManus <>
Date: Tuesday, 5. November 2019 at 22:37
To: "Su, Chi-Jiun" <>
Cc: "" <>rg>, "" <>rg>, Mirja Kuehlewind <>om>, Zaheduzzaman Sarker <>om>, Lucas Pardue <>
Subject: Re: [Masque] FW: New Version Notification for draft-kuehlewind-quic-proxy-discovery-00.txt

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 <<>> wrote:
Here are some more related to wpd for http:

From: Masque <<>> On Behalf Of Lucas Pardue
Sent: Monday, November 4, 2019 12:16 PM
To: Mirja Kuehlewind <<>>
Cc:<>; Zaheduzzaman Sarker <<>>;<>
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] -<>
[2] -<>
[3] -<>

On Mon, Nov 4, 2019 at 5:09 PM Mirja Kuehlewind <<>> 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 😊<>


From: Lucas Pardue <<>>
Date: Monday, 4. November 2019 at 18:06
To: Mirja Kuehlewind <<>>
Cc: "<>" <<>>, "<>" <<>>, Zaheduzzaman Sarker <<>>
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.


On Mon, Nov 4, 2019 at 4:58 PM Mirja Kuehlewind <<>> 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!


On 04.11.19, 17:53, "<>" <<>> 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:  <>

       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

       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<>I9PNQh7NkuA%24>.

    The IETF Secretariat

Masque mailing list<><>
Masque mailing list<>