- From: David Schinazi <dschinazi.ietf@gmail.com>
- Date: Wed, 14 Dec 2022 13:40:51 -0800
- To: Kazuho Oku <kazuhooku@gmail.com>
- Cc: Mark Nottingham <mnot@mnot.net>, Tommy Pauly <tpauly@apple.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAPDSy+41QGms7qzmZHAa=QQzWD8OWZ8VUCbU7am7gqNi3LMPDw@mail.gmail.com>
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 >
Received on Wednesday, 14 December 2022 21:41:16 UTC