- From: Martin Thomson <mt@lowentropy.net>
- Date: Fri, 16 Dec 2022 10:11:13 +1100
- To: ietf-http-wg@w3.org
I'm pretty ambivalent about this work. On the one hand, it is a fairly prosaic extension to a mechanism that already exists, with spelling that is broadly reasonable (modulo Kazuho's concerns, which I share). But the use cases are not very well articulated, which is something that needs work. Of those use cases, the one that appears to be behind this is detection of what is known as "CNAME cloaking". (Maybe I'm guessing, let me know.) Cloaking is where a "bad" actor asks a site operator to lend them a name so that they can avoid the consequences of doing whatever they were doing that earned them that "bad" label. Let's say that you host annoying stuff on annoying.example and you want to continue doing so, but your site has earned a place on various blocklists due to being annoying. You might be able to convince (or pay) example.com to lend you annoy.example.com, which - through the magic of CNAME or SVCB aliasing - can point to one of your servers. People who visit example.com can now interact with your service at annoy.example.com because this is a new name that is free from the taint associated with annoying.example. Operationally, this practice is cheap, but some browsers have learned to follow the trail of markers that are left by the DNS and restore the block on this alias. Of course, the obvious escalation is to have annoy.example.com include A records for the servers of the annoying service. At Mozilla, we concluded a while ago that we weren't interested in playing this game. I can go into reasons, but suffice it to say that we saw no positive outcome. That leaves me cold on this one. If others believe they have use cases, that is fine, but I would ask that the use cases be made more explicit either way, so that people have some hope of understanding what this provides in practice. Ta, Martin On Tue, Dec 6, 2022, at 15:19, Mark Nottingham wrote: > 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. > > 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/
Received on Thursday, 15 December 2022 23:11:49 UTC