HTTP Proxy-Status Parameter for Next-Hop Aliases

Tommy Pauly <tpauly@apple.com> Wed, 30 November 2022 22:16 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
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 94358C157B47 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Nov 2022 14:16:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.747
X-Spam-Level:
X-Spam-Status: No, score=-2.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 YdSTZCBWMSo3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Nov 2022 14:16:03 -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 6ACECC14F749 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 30 Nov 2022 14:16:02 -0800 (PST)
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1p0VKn-003OTQ-HV for ietf-http-wg-dist@listhub.w3.org; Wed, 30 Nov 2022 22:13:41 +0000
Resent-Date: Wed, 30 Nov 2022 22:13:41 +0000
Resent-Message-Id: <E1p0VKn-003OTQ-HV@lyra.w3.org>
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 <tpauly@apple.com>) id 1p0VKm-003OSS-3f for ietf-http-wg@listhub.w3.org; Wed, 30 Nov 2022 22:13:40 +0000
Received: from rn-mailsvcp-ppex-lapp35.apple.com ([17.179.253.44]) by mimas.w3.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tpauly@apple.com>) id 1p0VKk-004MMb-2C for ietf-http-wg@w3.org; Wed, 30 Nov 2022 22:13:39 +0000
Received: from pps.filterd (rn-mailsvcp-ppex-lapp35.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp35.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 2AUMDOhO026636; Wed, 30 Nov 2022 14:13:24 -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=+wc1EmMsqyKqrzlJRoWQSCIqVwEiiUhSwJAy94n9/lY=; b=QnOudIUvHxGs8XQBuBq6eLIhMFn1jCHxGVxX2egbSHk+Petkzi/+luu4PowXxEqL/VBg 5UWDVhys2IfkaP6Faka59F/eVm0ccZft6GkzdRLBTBsJJ1nbjsMKSyRTvsxWtM903Ilj 3u3nPYIQngPC6bGdbq2kQLJWMNGvnF6+wQWEzluA2pDcdmoOJUw2SPKlkQjGPHKq+MMF dyUKJozcMPympal4TClCXBzY3OTeimdsW2XqtyYeaLXhb7GHtjUbaaHb/k2WPSXhI3Aj ugS9K9NYUDyTNa1+Pncaf4DdV/Xcokmes1Jz0F0/sVefqfXjV6tfaj4HwcFcGNzkC2xS EQ==
Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp35.rno.apple.com with ESMTP id 3m62jq96s6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 30 Nov 2022 14:13:24 -0800
Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) 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 <0RM6007JCLQCG2L0@rn-mailsvcp-mta-lapp02.rno.apple.com>; Wed, 30 Nov 2022 14:13:24 -0800 (PST)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.20.20220923 64bit (built Sep 23 2022)) id <0RM600W00L49SU00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 30 Nov 2022 14:13:24 -0800 (PST)
X-Va-A:
X-Va-T-CD: aeebd4fdd5963ddcce0b17227227efb6
X-Va-E-CD: 437c365fc9c12b4881af93d464bad22e
X-Va-R-CD: a94bb45d3ab1dcbf74619363ce01db83
X-Va-CD: 0
X-Va-ID: 5414a6cc-1b7e-41d9-af9b-a84477365a2e
X-V-A:
X-V-T-CD: aeebd4fdd5963ddcce0b17227227efb6
X-V-E-CD: 437c365fc9c12b4881af93d464bad22e
X-V-R-CD: a94bb45d3ab1dcbf74619363ce01db83
X-V-CD: 0
X-V-ID: b9a72bba-efe2-478c-9ce7-0e629acadd70
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.545,18.0.895 definitions=2022-11-30_04:2022-11-30,2022-11-30 signatures=0
Received: from smtpclient.apple ([17.11.224.70]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.20.20220923 64bit (built Sep 23 2022)) with ESMTPSA id <0RM600Y18LQB2900@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 30 Nov 2022 14:13:23 -0800 (PST)
From: Tommy Pauly <tpauly@apple.com>
Message-id: <BC9076D0-8F74-4D2D-B933-81BE5D1ED52B@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_51F5C437-F9D7-4ED1-8B58-FECDD30B9AE3"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.2\))
Date: Wed, 30 Nov 2022 14:13:12 -0800
In-reply-to: <C91FC9A7-661D-4E8B-BE09-AD96EE7E3C4C@mnot.net>
Cc: Mark Nottingham <mnot@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>
References: <4D32628F-B514-4B9E-9F50-9FDA652A59B6@apple.com> <B18ACDAA-3B4C-48C7-B759-749EDF3FAA4E@apple.com> <C91FC9A7-661D-4E8B-BE09-AD96EE7E3C4C@mnot.net>
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.895 definitions=2022-11-30_04:2022-11-30,2022-11-30 signatures=0
Received-SPF: pass client-ip=17.179.253.44; envelope-from=tpauly@apple.com; helo=rn-mailsvcp-ppex-lapp35.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, RCVD_IN_MSPIKE_H2=-0.001, 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 1p0VKk-004MMb-2C 4e5a1ce9566db8c0fd3fb87351464472
X-Original-To: ietf-http-wg@w3.org
Subject: HTTP Proxy-Status Parameter for Next-Hop Aliases
Archived-At: <https://www.w3.org/mid/BC9076D0-8F74-4D2D-B933-81BE5D1ED52B@apple.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40586
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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/
>