Re: Call for Adoption: HTTP Proxy-Status Parameter for Next-Hop Aliases

I also support adoption.  The scope seems to be narrowly defined, but
giving clients
more visibility into this aspect of the endpoint they are connecting to
through a proxy
does seem worthwhile.

On Wed, Dec 14, 2022 at 4:44 PM David Schinazi <dschinazi.ietf@gmail.com>
wrote:

> I also support adoption, we have a real-world use case for this.
> David
>
> On Tue, Dec 6, 2022 at 4:59 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
>
>>
>>
>> 2022年12月6日(火) 13:21 Mark Nottingham <mnot@mnot.net>:
>>
>>> Tommy et al,
>>>
>>> This draft (or the protocol elements it defines) have been talked about
>>> in a few different places, so let's do a Call for Adoption to find out.
>>>
>>> This message opens a Call for Adoption for
>>> draft-pauly-httpbis-alias-proxy-status:
>>>
>>> https://www.ietf.org/archive/id/draft-pauly-httpbis-alias-proxy-status-00.html
>>>
>>> For the purposes of this CfA, assume that the proposed scope of work is
>>> as described -- just adding the `next-hop-alias` parameter, with any
>>> further work to be taken on separately.
>>>
>>> Please respond to indicate whether you support this work, that scope,
>>> and whether you intend to implement or use it.
>>>
>>
>> This is a nice and clean draft that IIUC serves real use-cases. We plan
>> to implement and deploy this extension.
>>
>> Aside from my +1 to adoption, I might state that the design looked good
>> to me as well. Initially, I was a bit surprised that the names have to be
>> concatenated as sf-string rather than using an array type of Structured
>> Headers. But I assume that's because we cannot have a list within an
>> sf-item. Therefore, we have to build an array outside of Structured Headers.
>>
>>
>>>
>>> The CfA will last for two weeks, ending on 20 December.
>>>
>>> Cheers,
>>>
>>>
>>> > On 1 Dec 2022, at 9:13 am, Tommy Pauly <tpauly@apple.com> wrote:
>>> >
>>> > Hello HTTP,
>>> >
>>> > Following up on this discussion, I presented this at Masque at IETF
>>> 115, and got the feedback that this would be fit more in HTTP, and also
>>> that it should just be a simpler proxy-status parameter to include only the
>>> alias name chain (generally, the CNAME chain).
>>> >
>>> > I’ve revised the document, and it’s super short — just defining a
>>> “next-hop-aliases” parameter, which is a list of names.
>>> >
>>> >
>>> https://www.ietf.org/archive/id/draft-pauly-httpbis-alias-proxy-status-00.html
>>> >
>>> https://datatracker.ietf.org/doc/draft-pauly-httpbis-alias-proxy-status/
>>> >
>>> > There was also discussion in the meeting about having more work on
>>> broader solutions to get rich and complex DNS information back from
>>> proxies, but I’d like to get this simple proxy-status parameter registered
>>> separately. I’d appreciate people’s reviews and thoughts.
>>> >
>>> > Thanks,
>>> > Tommy
>>> >
>>> >
>>> >> On Oct 12, 2022, at 4:02 PM, Mark Nottingham <mnot@mnot.net> wrote:
>>> >>
>>> >> Speaking personally -- I don't have any strong feelings either way,
>>> as long as appropriate communication happens. If the use cases are for
>>> non-MASQUE proxying too (and it seems like they are), that might tilt it
>>> slightly towards HTTP.
>>> >>
>>> >> Cheers,
>>> >>
>>> >>
>>> >>> On 11 Oct 2022, at 2:46 am, Tommy Pauly <tpauly@apple.com> wrote:
>>> >>>
>>> >>> Hi HTTP,
>>> >>>
>>> >>> I wanted to share this draft with this group, which I’ve initially
>>> started discussion on in MASQUE.
>>> >>>
>>> >>> It’s a simple parameter addition to proxy-status, to let the proxy
>>> send back the IP and CNAME/alias chain it used to reach the next hop. This
>>> is useful for clients of CONNECT/CONNECT-UDP proxies that want to apply
>>> policies to specific IPs and CNAMEs (for tracker detection, cookie rules,
>>> etc).
>>> >>>
>>> >>> In addition to any reviews and feedback on the technical content,
>>> we’d like to know if this is something that the HTTPbis WG would like to
>>> own, or if it is fine letting the work happen in MASQUE and get review from
>>> HTTP.
>>> >>>
>>> >>> Best,
>>> >>> Tommy
>>> >>>
>>> >>>> Begin forwarded message:
>>> >>>>
>>> >>>> From: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
>>> >>>> Subject: [Masque] HTTP Proxy-Status Parameter for DNS Information
>>> >>>> Date: October 4, 2022 at 12:29:33 PM PDT
>>> >>>> To: masque@ietf.org
>>> >>>>
>>> >>>> Hello MASQUErs,
>>> >>>>
>>> >>>> I wanted to share this document with this group, since it is mainly
>>> applicable to MASQUE-style (CONNECT/CONNECT-UDP) proxies.
>>> >>>>
>>> >>>> Right now, when a client connects to a TCP or UDP server via the
>>> proxy using a hostname in the request, it doesn’t perform its own DNS, and
>>> thus doesn’t learn about the IP address of the server it ultimately is
>>> connected to, or the CNAME / AliasMode chain that was used to get to the IP
>>> address of the server. That’s generally fine, but there are use cases where
>>> clients may want to know the IP address or CNAMEs to detect cases where
>>> trackers are performing CNAME cloaking, etc.
>>> >>>>
>>> >>>> So, this is a very simple proposal to define a new, optional
>>> proxy-status parameter that can let MASQUE-style proxies tell clients about
>>> the IP address and CNAME chain from DNS.
>>> >>>>
>>> >>>>
>>> https://www.ietf.org/archive/id/draft-pauly-masque-dns-proxy-status-00.html
>>> >>>>
>>> >>>> This certainly does not solve all of the use cases where clients
>>> may want to know more DNS details (SVCB/HTTPS records for ECH, alpn
>>> support, etc), and I expect more work to be needed for those use cases.
>>> However, I believe this extra bit of information is something that is
>>> incrementally useful, easy to implement, and simple to define.
>>> >>>>
>>> >>>> Thoughts and feedback welcome!
>>> >>>>
>>> >>>> Thanks,
>>> >>>> Tommy
>>> >>>>
>>> >>>>> Begin forwarded message:
>>> >>>>>
>>> >>>>> From: internet-drafts@ietf.org
>>> >>>>> Subject: New Version Notification for
>>> draft-pauly-masque-dns-proxy-status-00.txt
>>> >>>>> Date: October 4, 2022 at 11:01:29 AM PDT
>>> >>>>> To: Tommy Pauly <tpauly@apple.com>
>>> >>>>>
>>> >>>>>
>>> >>>>> A new version of I-D, draft-pauly-masque-dns-proxy-status-00.txt
>>> >>>>> has been successfully submitted by Tommy Pauly and posted to the
>>> >>>>> IETF repository.
>>> >>>>>
>>> >>>>> Name: draft-pauly-masque-dns-proxy-status
>>> >>>>> Revision: 00
>>> >>>>> Title: HTTP Proxy-Status Parameter for DNS Information
>>> >>>>> Document date: 2022-10-04
>>> >>>>> Group: Individual Submission
>>> >>>>> Pages: 5
>>> >>>>> URL:
>>> https://www.ietf.org/archive/id/draft-pauly-masque-dns-proxy-status-00.txt
>>> >>>>> Status:
>>> https://datatracker.ietf.org/doc/draft-pauly-masque-dns-proxy-status/
>>> >>>>> Html:
>>> https://www.ietf.org/archive/id/draft-pauly-masque-dns-proxy-status-00.html
>>> >>>>> Htmlized:
>>> https://datatracker.ietf.org/doc/html/draft-pauly-masque-dns-proxy-status
>>> >>>>>
>>> >>>>>
>>> >>>>> Abstract:
>>> >>>>>  This document defines an HTTP Proxy-Status Parameter that contains
>>> >>>>>  the IP address and CNAME chain received over DNS that was used to
>>> >>>>>  establish the connection to the next hop.
>>> >>>>>
>>> >>>>> Discussion Venues
>>> >>>>>
>>> >>>>>  This note is to be removed before publishing as an RFC.
>>> >>>>>
>>> >>>>>  Source for this draft and an issue tracker can be found at
>>> >>>>>  https://github.com/tfpauly/privacy-proxy.
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> The IETF Secretariat
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>> --
>>> >>>> Masque mailing list
>>> >>>> Masque@ietf.org
>>> >>>> https://www.ietf.org/mailman/listinfo/masque
>>> >>>
>>> >>
>>> >> --
>>> >> Mark Nottingham   https://www.mnot.net/
>>> >>
>>> >
>>>
>>> --
>>> Mark Nottingham   https://www.mnot.net/
>>>
>>>
>>>
>>
>> --
>> Kazuho Oku
>>
>