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

Eric Rescorla <ekr@rtfm.com> Mon, 03 February 2020 12:57 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: masque@ietfa.amsl.com
Delivered-To: masque@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3AD1200C3 for <masque@ietfa.amsl.com>; Mon, 3 Feb 2020 04:57:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Zh95m_QB2Eeb for <masque@ietfa.amsl.com>; Mon, 3 Feb 2020 04:57:10 -0800 (PST)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 1855A1200BA for <masque@ietf.org>; Mon, 3 Feb 2020 04:57:10 -0800 (PST)
Received: by mail-lf1-x131.google.com with SMTP id z26so9565500lfg.13 for <masque@ietf.org>; Mon, 03 Feb 2020 04:57:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OaYSuWG6Gxa9etJyJiule860qrCzQlv+TOucaHoCy0k=; b=lCeN0765EfblD3a2Q6h/W+T415bSS3VRihW4JIQbLav47rx/W1VLbfJq2A4YfuBQyD 5KxbI5O2mks47tkObulKEOLho1NPpsNyWjn+FHITo21PEqZ0pVZ/v2Md4xglLW4OlFY4 yi0a7buArgDZ4GY7qsQZj7Ncqq6x8GblMuvoYN6Kh6KQ00rstMcV9crfsOKfmNbUJcVy +ybqEeapA8+nR7h9sy4w/H7rW8FztSyRm4dZyG2IezLsltEt3hvqiuwDUanyDogd2Bck RAdYwYcux4qeMe4qxeEnoTbDdbQ3l8hSg06x5s9DyK8raFKIWtQjoJ7KjDJxD0viIBC+ JLOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OaYSuWG6Gxa9etJyJiule860qrCzQlv+TOucaHoCy0k=; b=ZhHLSJobqNRe/pl0IijAN4r5Rwuim164GzE8DrY/cths72O40Xxwc0mASyHtF9ewgk dRtC/nhaBpuIesdd65qkTeo/JfruE9NFlz/VhfzMefEjowtKXtwHT1tjZRIcgxgNjFm9 OIvJlg1qxPgBqErF/o16tryF2HrhoiVx8lh1x15H1eogr5xho8bwgplqXaPFfblzuWZ/ GJnvNLhGKiZ6vCiARihdmBxRuVtslDJfcc6OwBdbH5c/O9CrZQX+/ViggG34rVE/TEgP jzpT6sfuvEnjh2yBdopkjxM926rxxi7vVIt5A9SNTU3vhP7v65+ZC76dB7PSf8gKQEO5 CScw==
X-Gm-Message-State: APjAAAUHepSaKvkZVSpll+rtcm/aYlnZ8KKMSju5S/jaBLQyp23gMoxc RLhOPLyNj//vh4nXsACIy02+vu8Rd5PUVMiL3pC9xQ==
X-Google-Smtp-Source: APXvYqxDQ954uy8qlQZSoP3u6stcX0698RrFYO/sjp29urRIK44C7TvVfEAmXusZF/uw1yLjXjL1QToInBfMZ2RG7v4=
X-Received: by 2002:ac2:53b9:: with SMTP id j25mr11703955lfh.140.1580734628163; Mon, 03 Feb 2020 04:57:08 -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> <CAOdDvNruDZuBYp2ABfWCKMF4o6rY5Qk6x6ofH1qCJgLfKpsCUg@mail.gmail.com> <65CD80F2-11BF-4D48-A011-17F6E431D209@ericsson.com>
In-Reply-To: <65CD80F2-11BF-4D48-A011-17F6E431D209@ericsson.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 3 Feb 2020 04:56:31 -0800
Message-ID: <CABcZeBMd+1X674qJcxLpD2CGPSduO8G1rM1s-r_ccXXy7pn++A@mail.gmail.com>
To: Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>
Cc: Patrick McManus <mcmanus@ducksong.com>, Lucas Pardue <lucaspardue.24.7@gmail.com>, "quic@ietf.org" <quic@ietf.org>, "Su, Chi-Jiun" <Chi-Jiun.Su@hughes.com>, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>, "masque@ietf.org" <masque@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ff05fd059dab7563"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/ovIEAiD10d1CGdT5ecZqNPhkEC8>
Subject: Re: [Masque] FW: New Version Notification for draft-kuehlewind-quic-proxy-discovery-00.txt
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiplexed Application Substrate over QUIC Encryption <masque.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/masque>, <mailto:masque-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/masque/>
List-Post: <mailto:masque@ietf.org>
List-Help: <mailto:masque-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/masque>, <mailto:masque-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2020 12:57:13 -0000

On Wed, Jan 22, 2020 at 5:54 AM Mirja Kuehlewind <mirja.kuehlewind=
40ericsson.com@dmarc.ietf.org> wrote:

> 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.
>

Well,  one of the most common reasons why you would want some sort of
tunnel proxy is to conceal your behavior from the local network, which is
clearly inconsistent with having the local network supply the proxy
information.

More generally, I find the whole premise of this draft somewhat confusing.
If we look at TLS MITM proxies as a loose analogy, there are two kinds of
configuration one might want:

1. To tell the client to trust the proxy
2. To tell the client to connect to the proxy

However, as a practical matter, TLS MITM proxies don't do (2) and just rely
on network mechanisms to make that work. They only configure trust anchors
to let the client trust the proxy. Similarly here, the challenge with QUIC
is that you want the client to engage in some behavior that has trust
implications, but for this you need some discovery mechanism that is
secure, which the ones you propose are not.

-Ekr