W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2022

Fwd: [Masque] HTTP Proxy-Status Parameter for DNS Information

From: Tommy Pauly <tpauly@apple.com>
Date: Mon, 10 Oct 2022 08:46:01 -0700
Message-id: <B18ACDAA-3B4C-48C7-B759-749EDF3FAA4E@apple.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
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


Received on Monday, 10 October 2022 15:46:25 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 1 February 2023 02:18:31 UTC