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