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

[David Schinazi <[e-mail]>]

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 <[e-mail]> wrote:

>
>
> 2022年12月6日(火) 13:21 Mark Nottingham <[e-mail]>:
>
>> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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=[e-mail]>
>> >>>> Subject: [Masque] HTTP Proxy-Status Parameter for DNS Information
>> >>>> Date: October 4, 2022 at 12:29:33 PM PDT
>> >>>> To: [e-mail]
>> >>>>
>> >>>> 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: [e-mail]
>> >>>>> 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 <[e-mail]>
>> >>>>>
>> >>>>>
>> >>>>> 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
>> >>>> [e-mail]
>> >>>> https://www.ietf.org/mailman/listinfo/masque
>> >>>
>> >>
>> >> --
>> >> Mark Nottingham   https://www.mnot.net/
>> >>
>> >
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>>
>>
>
> --
> Kazuho Oku
>