Re: Call for Adoption: HTTP Proxy-Status Parameter for Next-Hop Aliases
Kazuho Oku <kazuhooku@gmail.com> Wed, 07 December 2022 00:58 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 64209C14CE2A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 6 Dec 2022 16:58:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.746
X-Spam-Level:
X-Spam-Status: No, score=-2.746 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_DNSWL_BLOCKED=0.001, 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=gmail.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 GUHFVahg9Poi for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 6 Dec 2022 16:58:46 -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 4073FC151706 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 6 Dec 2022 16:58:45 -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 1p2ijf-003uqa-Ky for ietf-http-wg-dist@listhub.w3.org; Wed, 07 Dec 2022 00:56:31 +0000
Resent-Date: Wed, 07 Dec 2022 00:56:31 +0000
Resent-Message-Id: <E1p2ijf-003uqa-Ky@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 <kazuhooku@gmail.com>) id 1p2ijd-003upi-K2 for ietf-http-wg@listhub.w3.org; Wed, 07 Dec 2022 00:56:29 +0000
Received: from mail-ej1-x631.google.com ([2a00:1450:4864:20::631]) by mimas.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <kazuhooku@gmail.com>) id 1p2ijb-008Sik-Hi for ietf-http-wg@w3.org; Wed, 07 Dec 2022 00:56:29 +0000
Received: by mail-ej1-x631.google.com with SMTP id qk9so10448505ejc.3 for <ietf-http-wg@w3.org>; Tue, 06 Dec 2022 16:56:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ooqOc/0w8xk+3Z6pHeDox8s6NZHelX09J1iYREf3eH8=; b=XKYkMHiNSZcA1KCM6LqLT2kkQuwu0SrpD7592NBInpk2Fm/lqNFoqkf5Jg5KKvF0Jw 6W0AmZNimKJj60aRqH2k7peKh9ZrEFZA55E1MqNLVXrPY4YiWAl6OeKAJM2ZpxEVJgSa GBZC29m7WaXI+OwYJYOzm2AipqIqkBgrBP1D06fWVnos4DVH3tTBX8kdrW/gDzPGJlaK NFyuvhYKIRhh61TUUkWZslyiMK3C13pZht9HUiv4OakKUq9RtpxtN1HZcPhWHFRbvv9g Bdg+X+ypKzL7YlkM/OeWqAljgfX6JYBdZwbYKKxYxd6mG4SXdH1s+4kjyGh9V/alYewL vQdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ooqOc/0w8xk+3Z6pHeDox8s6NZHelX09J1iYREf3eH8=; b=p1ZH8HxaoIoglkM6AcDF2gW+5JuOGorog5Sizd21tT/UIxwbdtDomPYMsNXnhvSiIY NmvXcfzZfrFbenba6WnBX9ZzB86Klayn94zuvVKUAMljByGE8N4k6f0UUw0WoM+ACjgN 5FFlsYIHjRBiuaEmydA5yCHqGvQO7sQow809i6IiqO/4juFHPQ1qUFbwK1qUEp7iS788 Rr+/XV/U/iZLXlKa+nSNHnInwC3umWXb7A3KXEO5R/uClYdDLElu86p5dIxBs2jjYP+6 KzUGszr2Jg8Jx/4X24rlj5MgTbQngjVsCcqfMZu2aN4PlGezt8JWRbF5DuNUtXg1lNWq 7XWA==
X-Gm-Message-State: ANoB5pmR4f0KLYAYOnuGOdGT3yxVwdp8zGm7XSti20eVSwEKhdvbolwL xkc04mHtXYGhvOLB0rnAEg4zwEbdV402zdJQSVU=
X-Google-Smtp-Source: AA0mqf5fgcTYLG9UGfxfvV6Rf6QMyJhNBkCrAkLwN4fl2vwN/XeC71d5b8d+W9OYifhvrqUXHiqHUbX+VBRKX00dVk8=
X-Received: by 2002:a17:906:70c2:b0:7ae:d58e:3a4a with SMTP id g2-20020a17090670c200b007aed58e3a4amr59613875ejk.332.1670374576246; Tue, 06 Dec 2022 16:56:16 -0800 (PST)
MIME-Version: 1.0
References: <4D32628F-B514-4B9E-9F50-9FDA652A59B6@apple.com> <B18ACDAA-3B4C-48C7-B759-749EDF3FAA4E@apple.com> <C91FC9A7-661D-4E8B-BE09-AD96EE7E3C4C@mnot.net> <BC9076D0-8F74-4D2D-B933-81BE5D1ED52B@apple.com> <D7F36608-94A2-449A-B3D8-83DF2E8A0AF1@mnot.net>
In-Reply-To: <D7F36608-94A2-449A-B3D8-83DF2E8A0AF1@mnot.net>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Wed, 07 Dec 2022 09:56:04 +0900
Message-ID: <CANatvzxeczZqYV_YDH85BTjgGYG510V1Q=8BjOgLEVujE+BKUA@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Tommy Pauly <tpauly@apple.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="00000000000042564005ef326335"
Received-SPF: pass client-ip=2a00:1450:4864:20::631; envelope-from=kazuhooku@gmail.com; helo=mail-ej1-x631.google.com
X-W3C-Hub-DKIM-Status: validation passed: (address=kazuhooku@gmail.com domain=gmail.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1p2ijb-008Sik-Hi 912bf3a782b92fb713a8d5f9e6c76007
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Call for Adoption: HTTP Proxy-Status Parameter for Next-Hop Aliases
Archived-At: <https://www.w3.org/mid/CANatvzxeczZqYV_YDH85BTjgGYG510V1Q=8BjOgLEVujE+BKUA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40647
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>
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
- Fwd: [Masque] HTTP Proxy-Status Parameter for DNS… Tommy Pauly
- Re: [Masque] HTTP Proxy-Status Parameter for DNS … Mark Nottingham
- HTTP Proxy-Status Parameter for Next-Hop Aliases Tommy Pauly
- Re: HTTP Proxy-Status Parameter for Next-Hop Alia… Glenn Strauss
- Re: HTTP Proxy-Status Parameter for Next-Hop Alia… Erik Nygren
- Call for Adoption: HTTP Proxy-Status Parameter fo… Mark Nottingham
- Re: Call for Adoption: HTTP Proxy-Status Paramete… Kazuho Oku
- Re: HTTP Proxy-Status Parameter for Next-Hop Alia… Tommy Pauly
- Re: HTTP Proxy-Status Parameter for Next-Hop Alia… Lucas Pardue
- Re: Call for Adoption: HTTP Proxy-Status Paramete… David Schinazi
- Re: Call for Adoption: HTTP Proxy-Status Paramete… Martin Thomson
- Re: Call for Adoption: HTTP Proxy-Status Paramete… Erik Nygren
- Re: Call for Adoption: HTTP Proxy-Status Paramete… Mark Nottingham