Re: [Masque] Benjamin Kaduk's No Objection on charter-ietf-masque-00-00: (with COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Thu, 21 May 2020 00:32 UTC
Return-Path: <kaduk@mit.edu>
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 C233E3A0940; Wed, 20 May 2020 17:32:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 L8DJCC4GY4ge; Wed, 20 May 2020 17:31:59 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 091CA3A093E; Wed, 20 May 2020 17:31:58 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04L0Vrwg032147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 May 2020 20:31:55 -0400
Date: Wed, 20 May 2020 17:31:52 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Martin Duke <martin.h.duke@gmail.com>
Cc: The IESG <iesg@ietf.org>, masque-chairs@ietf.org, MASQUE <masque@ietf.org>
Message-ID: <20200521003152.GC58497@kduck.mit.edu>
References: <158999499543.12397.7137358356514385454@ietfa.amsl.com> <CAM4esxT0Cr46QLa_8fKqk8XE19gvY8t=5sJg1w6W06HGmAj+CQ@mail.gmail.com> <CAM4esxSjAWbd6Jbn7YjMdPW2zx1=a+XaxwHRUZRAgVR1vbYusg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAM4esxSjAWbd6Jbn7YjMdPW2zx1=a+XaxwHRUZRAgVR1vbYusg@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/ha9YpwwHsBn0abfmAFkKjwwZN7E>
Subject: Re: [Masque] Benjamin Kaduk's No Objection on charter-ietf-masque-00-00: (with COMMENT)
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: Thu, 21 May 2020 00:32:02 -0000
Thanks, the as-merged version of the PR looks good. -Ben On Wed, May 20, 2020 at 03:49:13PM -0700, Martin Duke wrote: > After wordsmithing with the chairs, a revised edits: > > The last service discovery clause now reads: "However, the group may > consider features, such as proxy server identifiers, that aid future > discovery mechanisms." > > On Wed, May 20, 2020 at 3:11 PM Martin Duke <martin.h.duke@gmail.com> wrote: > > > Thanks Ben, replies inline. > > > > Please see this PR to see the changes in context: > > https://github.com/chris-wood/ietf-masque/pull/7 > > > > > > On Wed, May 20, 2020 at 10:16 AM Benjamin Kaduk via Datatracker < > > noreply@ietf.org> wrote: > > > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> Just "HTTP" does not imply any particular level of security mechanism, > >> though > >> "HTTP/3" would. I think we need to say something about what security > >> properties we expect MASQUE to provide, even if it's just "equivalent to > >> HTTP/3 > >> or better". (This would be a BLOCK at external-review time but may not > >> need to > >> hold up asking for external review.) > >> > > > > [MD] Shall I simply change HTTP to HTTPS? There is not an intent to run > > this over plaintext HTTP. > > > > > >> > >> Proxying technologies such as SOCKS and HTTP(S) CONNECT exist, albeit > >> with > >> their own shortcomings. For example, SOCKS signalling is not encrypted > >> and HTTP > >> CONNECT is currently limited to TCP. In contrast, HTTP/3 is a viable > >> candidate > >> protocol for proxying arbitrary traffic, as it provides secure > >> connectivity, > >> multiplexed streams, and migration for a single connection while taking > >> advantage of a unified congestion controller. An HTTP/3 datagram > >> construct > >> > >> Am I parsing this properly that the last thing in the list of what HTTP/3 > >> provides is just "migration", and that the "for a single connection [...]" > >> stuff applies to all of it? I'm not sure if another comma would help make > >> that separation more clear. > >> > > > > [MD] Clarified to make it clear "for a single connection" applies to all > > of it. > > > > > >> > >> The primary goal of this working group is to develop mechanisms that > >> allow > >> > >> nit: maybe "mechanism(s)"? > >> > > > > [MD] done > > > > and/or HTTP/3 extensions to enable this functionality. The group will > >> focus on > >> a limited set of client-initiated services: (1) UDP CONNECT and (2) IP > >> proxying. Server-initiated services are out of scope. The working group > >> will > >> first deliver a protocol solution for UDP CONNECT and a requirements > >> document > >> for IP proxying. Once both are complete, the working group will focus > >> on a > >> protocol solution for IP proxying. > >> > >> I assume there's a reason to do UDP separately instead of just letting UDP > >> run on top of proxied IP. (Expediency?) > >> > > > > [MD] Yes, IP proxying raises a number of issues about addresses, etc. that > > make it much more challenging. UDP proxying covers most use cases, likely > > neatly corresponds to HTTP CONNECT, and has less packet overhead. > > > > > >> > >> The working group will consider fallback to versions of HTTP that > >> operate over > >> TCP as a mitigation to UDP or HTTP/3 blocking. Moreover, the working > >> group will > >> consider implications of tunneling protocols with congestion control > >> and loss > >> recovery over MASQUE, and may issue recommendations accordingly. New > >> congestion > >> > >> This sounds like "nested congestion controllers". Is that more of a > >> research > >> question or an engineering one? > >> > > > > [MD] A true nested congestion controller would indeed be research into a > > new algorithm, which is forbidden in the charter. Instead, the WG will make > > some sensible recommendations to tune existing congestion controls, e.g. > > "turn off the outer congestion control" or "raise the reordering threshold > > on the inner loss recovery". > > > > > >> Multicast UDP and multicast IP support are out of scope. However, the > >> group may > >> specify extension points that would enable future work on multicast. > >> Specifying > >> proxy server discovery mechanisms is also out of scope, but the group > >> may > >> specify techniques for identifying proxy servers to aid future discovery > >> mechanisms. > >> > >> How do "techniques" differ from "mechanisms"? > >> > > > > [MD] One is a service discovery protocol, the other is some sort of server > > identifier and capability report that a future service might use. IIUC DoH > > had a similar split. > > > > I changed it to "... but the group may specify identifiers and capability > > reports for proxy servers to aid future discovery mechanisms." > > > > > >> > >> Impacts on address migration, NAT rebinding, and future multipath > >> mechanisms of > >> QUIC are not anticipated. However, the working group should document > >> these > >> impacts if they arise. > >> > >> Presumably we also want to pay attention to any other developments in QUIC > >> that would be impacted by MASQUE, and document those, too. > >> > > > > [MD] added > > > >> > >> > >> > >> -- > >> Masque mailing list > >> Masque@ietf.org > >> https://www.ietf.org/mailman/listinfo/masque > >> > >
- [Masque] Benjamin Kaduk's No Objection on charter… Benjamin Kaduk via Datatracker
- Re: [Masque] Benjamin Kaduk's No Objection on cha… Martin Duke
- Re: [Masque] Benjamin Kaduk's No Objection on cha… Martin Duke
- Re: [Masque] Benjamin Kaduk's No Objection on cha… Benjamin Kaduk