From ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org Fri Dec 9 09:32:16 2022 Return-Path: X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4975C13B4CF for ; Fri, 9 Dec 2022 09:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.049 X-Spam-Level: X-Spam-Status: No, score=-5.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBuFqLYp7A31 for ; Fri, 9 Dec 2022 09:32:12 -0800 (PST) Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B40C15C95F for ; Fri, 9 Dec 2022 09:32:11 -0800 (PST) Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from ) id 1p3hCY-00DNSM-48 for ietf-http-wg-dist@listhub.w3.org; Fri, 09 Dec 2022 17:30:22 +0000 Resent-Date: Fri, 09 Dec 2022 17:30:22 +0000 Resent-Message-Id: Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1p3hCW-00DNQy-R9 for ietf-http-wg@listhub.w3.org; Fri, 09 Dec 2022 17:30:20 +0000 Received: from rn-mailsvcp-ppex-lapp14.rno.apple.com ([17.179.253.33] helo=rn-mailsvcp-ppex-lapp14.apple.com) by mimas.w3.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1p3hCU-00AIbL-GQ for ietf-http-wg@w3.org; Fri, 09 Dec 2022 17:30:20 +0000 Received: from pps.filterd (rn-mailsvcp-ppex-lapp14.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp14.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 2B9HT7X8032764; Fri, 9 Dec 2022 09:30:05 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=JvkLjhpCKt6NXnqbvlErSszegPj/NlZCzLvWuu5bfwk=; b=IBTElkkmiDrBtTU2Z5DM+DXmMOXV+4rt/wDfP7PbRrH5D3wxrIddHsMPqtjG3K/WDXr2 XUVvDv0q1V2G5yRZd7JddeUSqrlD8kQTsRWaPRrtlEJ4A416fU4WVQjahxz1Iigq/LA4 0crmOSRNvHm1pb7P6X/hnTOl1E8MPLsPr8PzLXYAf1IJrg1ZWY2p5I9BJqc071HFII0B j1SzEnIe/z3Cf7TsJjtLiZcbf21tvvS7KGym+5lrVWPcWOjaIvGrsTJK9xOdxqojPquQ hVcvVWVysIak/7428BJiUDZNt2APXrkT2XKrO19GqlaqhnSw2nsG+0xvsm407Td1rGbf uQ== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp14.rno.apple.com with ESMTP id 3m93fgrbnr-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 09 Dec 2022 09:30:05 -0800 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.20.20220923 64bit (built Sep 23 2022)) with ESMTPS id <0RMM00U9WWM5UKH0@rn-mailsvcp-mta-lapp02.rno.apple.com>; Fri, 09 Dec 2022 09:30:05 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.20.20220923 64bit (built Sep 23 2022)) id <0RMM01100W68BJ00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Fri, 09 Dec 2022 09:30:05 -0800 (PST) X-Va-A: X-Va-T-CD: cf81a03552d72e88b2c7c1a9075a2c16 X-Va-E-CD: 672e948c010c95c4450fa5f36ff9cc9f X-Va-R-CD: d1f0ae016da512962e09a7c2eeacc4da X-Va-CD: 0 X-Va-ID: be4ac5fc-cd63-4213-996c-2f066a904dec X-V-A: X-V-T-CD: cf81a03552d72e88b2c7c1a9075a2c16 X-V-E-CD: 672e948c010c95c4450fa5f36ff9cc9f X-V-R-CD: d1f0ae016da512962e09a7c2eeacc4da X-V-CD: 0 X-V-ID: 610ce63c-9450-4b30-970d-53d4759894f6 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.545,18.0.923 definitions=2022-12-09_10:2022-12-08,2022-12-09 signatures=0 Received: from smtpclient.apple ([17.11.54.6]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.20.20220923 64bit (built Sep 23 2022)) with ESMTPSA id <0RMM00VRHWM12400@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Fri, 09 Dec 2022 09:30:05 -0800 (PST) From: Tommy Pauly Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_13931E5F-A1F6-40C7-A33A-CD3B5AA3A42F" MIME-version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.2\)) Date: Fri, 09 Dec 2022 09:29:51 -0800 In-reply-to: Cc: "ietf-http-wg@w3.org Group" To: Erik Nygren References: X-Mailer: Apple Mail (2.3731.300.101.1.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.545,18.0.923 definitions=2022-12-09_10:2022-12-08,2022-12-09 signatures=0 Received-SPF: pass client-ip=17.179.253.33; envelope-from=tpauly@apple.com; helo=rn-mailsvcp-ppex-lapp14.apple.com X-W3C-Hub-DKIM-Status: validation passed: (address=tpauly@apple.com domain=apple.com), signature is good X-W3C-Hub-Spam-Status: No, score=-11.4 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1 X-W3C-Scan-Sig: mimas.w3.org 1p3hCU-00AIbL-GQ a1936fc80c6db55203ce6f4128aec41d X-Original-To: ietf-http-wg@w3.org Subject: Re: HTTP Proxy-Status Parameter for Next-Hop Aliases Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/40649 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --Apple-Mail=_13931E5F-A1F6-40C7-A33A-CD3B5AA3A42F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Erik, Thanks for the review! Comments below. > On Dec 1, 2022, at 9:34 AM, Erik Nygren wrote: >=20 > I'd agree that HTTP makes more sense since this seems generally useful = for proxies. >=20 > I'd be in-favor of the HTTP WG doing this. I think it will be = important=20 > to loop in DNSOP and/or the new DNS Directorate in as well since there > may be some important corner-cases from them to consider. >=20 > Some thoughts also opened at: > https://github.com/tfpauly/privacy-proxy/issues/229 > https://github.com/tfpauly/privacy-proxy/issues/230 >=20 > 1) Per draft-ietf-dnsop-svcb-https-11 section 3.2 clients MUST send = the final TargetName to proxies: > = https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-11#secti= on-3.2 > Proxies themselves shouldn't be doing SVCB/HTTPS RR lookups to get = A/AAAA records. > As such, draft-pauly-httpbis-alias-proxy-status only needs to look at = CNAME chains. Thanks, I=E2=80=99ve removed the SVCB reference with this PR: = https://github.com/tfpauly/privacy-proxy/pull/231 >=20 > 2) Is any special handling needed for exposing DNAMEs? Or are those = not visible to resolver libraries. I think the latter, but not sure. I=E2=80=99ve looked into this, and I believe this shouldn=E2=80=99t = expose DNAMEs, from my understanding. The resolver library seems like it = would normally just see the address records, or a synthesized CNAME = record. Let me know if I=E2=80=99ve missed something there. >=20 > These might also be worth considering, although we might decide they = are too much complexity: >=20 > 3) One of the use-cases for draft-pauly-httpbis-alias-proxy-status may = be for influencing connection coalescing behaviors. Since some clients = use "is the IP address that the proxy is connecting to overlapping with = the rrset(s) used by other connections" having the full IP address rrset = lists for A and AAAA responses might be worthwhile. While the connection-coalescing use case is interesting, I think it is = more complex and requires a way to request getting full sets of DNS RRs = back. The approach of proxy-status is to describe what was connected to, = and I don=E2=80=99t think it makes sense to add that information here. I = certainly think there=E2=80=99s room for new headers that would allow = clients to request specific DNS records from a proxy during CONNECT, but = that is a much larger and less clearly scoped direction. > 4) We may want to allow listing all IP addresses tried before = establishing the connection. (eg, a TCP proxy might implement happy = eyeballs and/or fail-over between multiple IP addresses.) Knowing which = others were tried but not used (when possible) might help for some of = the abuse/use cases. >=20 Again, I think this one would be out of scope (especially since this one = parameter is now just about aliases). It=E2=80=99s something to consider = going forward, though. Best, Tommy > Best, Erik >=20 >=20 >=20 >=20 >=20 >=20 > > Hello HTTP, > >=20 > > 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). > >=20 > > I=E2=80=99ve revised the document, and it=E2=80=99s super short =E2=80= =94 just defining a =E2=80=9Cnext-hop-aliases=E2=80=9D parameter, which = is a list of names. > >=20 > > = 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/ > >=20 > > 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=E2=80=99d like to get this simple proxy-status parameter = registered separately. I=E2=80=99d appreciate people=E2=80=99s reviews = and thoughts. > >=20 > > Thanks, > > Tommy > > > > On Oct 12, 2022, at 4:02 PM, Mark Nottingham > wrote: > >=20 > > 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. > >=20 > > Cheers, > >=20 > >=20 > >> On 11 Oct 2022, at 2:46 am, Tommy Pauly > wrote: > >>=20 > >> Hi HTTP, > >>=20 > >> I wanted to share this draft with this group, which I=E2=80=99ve = initially started discussion on in MASQUE. > >>=20 > >> It=E2=80=99s 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). > >>=20 > >> In addition to any reviews and feedback on the technical content, = we=E2=80=99d 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. > >>=20 > >> Best, > >> Tommy > >>=20 > >>> Begin forwarded message: > >>>=20 > >>> From: Tommy Pauly > > >>> Subject: [Masque] HTTP Proxy-Status Parameter for DNS Information > >>> Date: October 4, 2022 at 12:29:33 PM PDT > >>> To: masque@ietf.org = > >>>=20 > >>> Hello MASQUErs, > >>>=20 > >>> I wanted to share this document with this group, since it is = mainly applicable to MASQUE-style (CONNECT/CONNECT-UDP) proxies. > >>>=20 > >>> Right now, when a client connects to a TCP or UDP server via the = proxy using a hostname in the request, it doesn=E2=80=99t perform its = own DNS, and thus doesn=E2=80=99t 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=E2=80=99s = 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. > >>>=20 > >>> 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. > >>>=20 > >>> = https://www.ietf.org/archive/id/draft-pauly-masque-dns-proxy-status-00.htm= l > >>>=20 > >>> 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. > >>>=20 > >>> Thoughts and feedback welcome! > >>>=20 > >>> Thanks, > >>> Tommy > >>>=20 > >>>> Begin forwarded message: > >>>>=20 > >>>> 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 > > >>>>=20 > >>>>=20 > >>>> 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. > >>>>=20 > >>>> 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.htm= l > >>>> Htmlized: = https://datatracker.ietf.org/doc/html/draft-pauly-masque-dns-proxy-status > >>>>=20 > >>>>=20 > >>>> 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. > >>>>=20 > >>>> Discussion Venues > >>>>=20 > >>>> This note is to be removed before publishing as an RFC. > >>>>=20 > >>>> Source for this draft and an issue tracker can be found at > >>>> https://github.com/tfpauly/privacy-proxy. > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>> The IETF Secretariat > >>>>=20 > >>>>=20 > >>>=20 > >>> --=20 > >>> Masque mailing list > >>> Masque@ietf.org = > >>> https://www.ietf.org/mailman/listinfo/masque > >>=20 > >=20 > > -- > > Mark Nottingham https://www.mnot.net/ > >=20 --Apple-Mail=_13931E5F-A1F6-40C7-A33A-CD3B5AA3A42F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Erik,

Thanks for the review! Comments = below.

On Dec 1, 2022, = at 9:34 AM, Erik Nygren <erik+ietf@nygren.org> wrote:

I'd = agree that HTTP makes more sense since this seems generally useful for = proxies.

I'd be in-favor of the HTTP WG doing this.  I think = it will be important
to loop in DNSOP and/or the new DNS Directorate = in as well since there
may be some important corner-cases from them = to consider.

Some thoughts also opened at:
https://githu= b.com/tfpauly/privacy-proxy/issues/229
https://githu= b.com/tfpauly/privacy-proxy/issues/230

1) Per = draft-ietf-dnsop-svcb-https-11 section 3.2 clients MUST send the final = TargetName to proxies:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svc= b-https-11#section-3.2
Proxies themselves shouldn't be doing = SVCB/HTTPS RR lookups to get A/AAAA records.
As such, = draft-pauly-httpbis-alias-proxy-status only needs to look at CNAME = chains.

Thanks, I=E2=80=99= ve removed the SVCB reference with this PR: https://github.= com/tfpauly/privacy-proxy/pull/231

2) Is any special handling = needed for exposing DNAMEs? Or are those not visible to resolver = libraries.  I think the latter, but not = sure.

I=E2=80=99ve = looked into this, and I believe this shouldn=E2=80=99t expose DNAMEs, = from my understanding. The resolver library seems like it would normally = just see the address records, or a synthesized CNAME record. Let me know = if I=E2=80=99ve missed something there.


These = might also be worth considering, although we might decide they are too = much complexity:

3) One = of the use-cases for=20 draft-pauly-httpbis-alias-proxy-status may be for influencing connection coalescing behaviors. Since some clients use "is the IP address that=20= the proxy is connecting to overlapping with the rrset(s) used by other=20= connections" having the full IP address rrset lists for A and AAAA=20 responses might be = worthwhile.

While the = connection-coalescing use case is interesting, I think it is more = complex and requires a way to request getting full sets of DNS RRs back. = The approach of proxy-status is to describe what was connected to, and I = don=E2=80=99t think it makes sense to add that information here. I = certainly think there=E2=80=99s room for new headers that would allow = clients to request specific DNS records from a proxy during CONNECT, but = that is a much larger and less clearly scoped = direction.

4) We may want to allow listing all IP=20 addresses tried before establishing the connection. (eg, a TCP proxy=20 might implement happy eyeballs and/or fail-over between multiple IP=20 addresses.) Knowing which others were tried but not used (when=20 possible) might help for some of the abuse/use = cases.

Again, I think this one = would be out of scope (especially since this one parameter is now just = about aliases). It=E2=80=99s something to consider going forward, = though.

Best,
Tommy

Best, = Erik





> Hello HTTP,
>=20
> 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).
>=20
> I=E2=80=99ve revised the document, and it=E2=80=99s super short =E2=80=
=94 just defining a =E2=80=9Cnext-hop-aliases=E2=80=9D parameter, which =
is a list of names.
>=20
> https://www.ietf.org/archive/id/draft-pauly-httpbis-alias-pr=
oxy-status-00.html
https://datatracker.ietf.org/doc/draft-pauly-httpbis-alias-proxy-s=
tatus/
>=20
> 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=E2=80=99d like to get this simple proxy-status parameter =
registered separately. I=E2=80=99d appreciate people=E2=80=99s reviews =
and thoughts.
>=20
> Thanks,
> Tommy
>
> On Oct 12, 2022, at 4:02 PM, Mark Nottingham <mnot@mnot.net> wrote:
>=20
> 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.
>=20
> Cheers,
>=20
>=20
>> On 11 Oct 2022, at 2:46 am, Tommy Pauly <tpauly@apple.com> wrote:
>>=20
>> Hi HTTP,
>>=20
>> I wanted to share this draft with this group, which I=E2=80=99ve =
initially started discussion on in MASQUE.
>>=20
>> It=E2=80=99s 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).
>>=20
>> In addition to any reviews and feedback on the technical =
content, we=E2=80=99d 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.
>>=20
>> Best,
>> Tommy
>>=20
>>> Begin forwarded message:
>>>=20
>>> From: Tommy Pauly <tpauly=3D40apple.com@d=
marc.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
>>>=20
>>> Hello MASQUErs,
>>>=20
>>> I wanted to share this document with this group, since it =
is mainly applicable to MASQUE-style (CONNECT/CONNECT-UDP) proxies.
>>>=20
>>> Right now, when a client connects to a TCP or UDP server =
via the proxy using a hostname in the request, it doesn=E2=80=99t =
perform its own DNS, and thus doesn=E2=80=99t 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=E2=80=99s=
 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.
>>>=20
>>> 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.
>>>=20
>>> https://www.ietf.org/archive/id/draft-pauly-masque-dns-proxy-st=
atus-00.html
>>>=20
>>> 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.
>>>=20
>>> Thoughts and feedback welcome!
>>>=20
>>> Thanks,
>>> Tommy
>>>=20
>>>> Begin forwarded message:
>>>>=20
>>>> 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>
>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>> 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-sta=
tus-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-st=
atus-00.html
>>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-pauly-masque-dns-prox=
y-status
>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>> Discussion Venues
>>>>=20
>>>>  This note is to be removed before publishing as an =
RFC.
>>>>=20
>>>>  Source for this draft and an issue tracker can be =
found at
>>>>  https://github.com/tfpau=
ly/privacy-proxy.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> The IETF Secretariat
>>>>=20
>>>>=20
>>>=20
>>> --=20
>>> Masque mailing list
>>> Masque@ietf.org
>>> https://www.ietf.org=
/mailman/listinfo/masque
>>=20
>=20
> --
> Mark Nottingham   https://www.mnot.net/
>=20

= --Apple-Mail=_13931E5F-A1F6-40C7-A33A-CD3B5AA3A42F--