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

Eric Rescorla <ekr@rtfm.com> Mon, 03 February 2020 15:11 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 74D571200E9 for <masque@ietfa.amsl.com>; Mon, 3 Feb 2020 07:11:02 -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=ham 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 mAtWxfemT23e for <masque@ietfa.amsl.com>; Mon, 3 Feb 2020 07:11:00 -0800 (PST)
Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (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 1EDA61200CC for <masque@ietf.org>; Mon, 3 Feb 2020 07:11:00 -0800 (PST)
Received: by mail-lf1-x144.google.com with SMTP id t23so9956165lfk.6 for <masque@ietf.org>; Mon, 03 Feb 2020 07:11:00 -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=8ICAaytpjL3rbJM3nO+YfQq36YneRJDur6CUwKUHotE=; b=rYQzbudqs/ui+bRC66hDkvW83iaFL0y8oRZlNdDfAYObl0aCEh5WFkpYGUjcxqPJ8Z vGOkg+8VR+lBg6MG9TeXQlMjGBjVh9IC7rDr13FueImwoe53dMhIavZUR3bpOkM/LerV Dbtxl57reLceEGrxdq+fr84ITMDukmulZxCYhA+zEALbsLC0KbrldjWu9Mhc4CV0LGXr QKkqL2HBuVp//LPlcslrJIYwg6a7fpTdaFNmAgu2+ygFZ6S7IZLUyQ6r7C6ku+5+cx6V iaxiz9HPyGbEOOCmaUhXTFg6Cgv8/2Uz5sWQaH8me3QOwcSCamVzEEd+CHZyYNDKTrzx KIEw==
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=8ICAaytpjL3rbJM3nO+YfQq36YneRJDur6CUwKUHotE=; b=LpRs72lUbhDaJ4b+ijhb2T7rXIf8JPR/uI9ar2RC8E0fes4cKYosMgqKzafqIJeeDm K7ngHekT2raTSb1BP0BOQZXkBzsioNncy3OuapS5kCJrSla8ZIaNTgwErB5X2PRTzKJ4 AWryOQLen+8j+Zf26iX2+eZRiJZzCt4w9+U2k/M0Z/UfBysvstXdsqpty13o9Y+SoycG zkT3AC1IySRtdY3vk6dSVVm094Ia4rWeb2m/CdcQLJt5TjBgYwgCuEISN33JyDJEbx/M ITEitrb04pbBpyrSlDXOItZV/i69A3xV66NrE6akfCDbs2fGocsw4PY0KinB4OGFoIgW FT5Q==
X-Gm-Message-State: APjAAAWSyj+lARCOtvd4hf91PHPFebiKPhleNAFUZIiga/35VWKmx298 N/e5uFig9GMQIaZKJcRWBZ39jS6AwDGC0gHhc+fQwA==
X-Google-Smtp-Source: APXvYqyFnH2DUCguDOv7xSlulVJ90EY2+0XhMH6f9uZMQVMbhmoEgv+rMJoYKrOfwawqDSPG52tLhuv03BBQlV3M1FM=
X-Received: by 2002:a19:8b89:: with SMTP id n131mr12300108lfd.14.1580742658290; Mon, 03 Feb 2020 07:10:58 -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> <CABcZeBMd+1X674qJcxLpD2CGPSduO8G1rM1s-r_ccXXy7pn++A@mail.gmail.com> <9AA1F2AB-AF93-4A28-B258-3A691A4DCDEC@ericsson.com>
In-Reply-To: <9AA1F2AB-AF93-4A28-B258-3A691A4DCDEC@ericsson.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 3 Feb 2020 07:10:21 -0800
Message-ID: <CABcZeBPv7r53rwru6PaaUBHSNz685WmHM8n=+E+bJHV9AMRLuw@mail.gmail.com>
To: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
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="000000000000a1061b059dad543a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/GoyLgIoP0o_B2JBF1qJry-LpsrA>
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 15:11:02 -0000

On Mon, Feb 3, 2020 at 6:46 AM Mirja Kuehlewind <
mirja.kuehlewind@ericsson.com> wrote:

> Hi Ekr,
>
>
>
> TLS MITM is not the right analogy here. As I said in my email below we
> only look at services for the proxy could to provide that do not intercept
> the end-to-end connection.
>

Hence the phrase "loose analogy". Those service still require authorization
and the only authorization you are providing is network topology.

-Ekr



Instead the client would either request a certain network service from the
> proxy (in any case at least simple forwarding) or, what we have in mind for
> performance optimization, the proxy would provide additional information to
> the client that then can be used in the endpoints to optimize traffic.
>
>
>
> Further you can still configure a trust anchor in your client and use
> local recovery to dynamically find the IP address. And not all mechanisms
> described in the draft are actually for local recovery.
>
>
>
> And at the end it depends on the service the proxy provides if a local
> proxy makes sense or not. E.g. if you only look at forwarding and address
> translation in order to conceal the client IP address from the server, not
> that much trust is needed and a local proxy can make a lot of sense as your
> access provider knows you IP address anyway.
>

>
> Mirja
>
>
>
>
>
>
>
> *From: *Eric Rescorla <ekr@rtfm.com>
> *Date: *Monday, 3. February 2020 at 13:57
> *To: *Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
> *Cc: *Patrick McManus <mcmanus@ducksong.com>om>, Lucas Pardue <
> lucaspardue.24.7@gmail.com>gt;, "quic@ietf.org" <quic@ietf.org>rg>, "Su,
> Chi-Jiun" <Chi-Jiun.Su@hughes.com>om>, Zaheduzzaman Sarker <
> zaheduzzaman.sarker@ericsson.com>gt;, "masque@ietf.org" <masque@ietf.org>
> *Subject: *Re: [Masque] FW: New Version Notification for
> draft-kuehlewind-quic-proxy-discovery-00.txt
>
>
>
>
>
>
>
> 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
>
>
>