Re: Call for Adoption: HTTP Proxy-Status Parameter for Next-Hop Aliases
Erik Nygren <erik+ietf@nygren.org> Fri, 16 December 2022 19:10 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 B97A2C15170A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 16 Dec 2022 11:10:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.647
X-Spam-Level:
X-Spam-Status: No, score=-7.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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
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 QakRWvEjYvCg for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 16 Dec 2022 11:10:24 -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 013DAC14CF1E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 16 Dec 2022 11:10:18 -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 1p6G4N-000JCO-Rs for ietf-http-wg-dist@listhub.w3.org; Fri, 16 Dec 2022 19:08:31 +0000
Resent-Date: Fri, 16 Dec 2022 19:08:31 +0000
Resent-Message-Id: <E1p6G4N-000JCO-Rs@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 <nygren@gmail.com>) id 1p6G4M-000JBQ-35 for ietf-http-wg@listhub.w3.org; Fri, 16 Dec 2022 19:08:30 +0000
Received: from mail-wr1-f45.google.com ([209.85.221.45]) by mimas.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <nygren@gmail.com>) id 1p6G4K-00Dvq2-09 for ietf-http-wg@w3.org; Fri, 16 Dec 2022 19:08:29 +0000
Received: by mail-wr1-f45.google.com with SMTP id h10so3451946wrx.3 for <ietf-http-wg@w3.org>; Fri, 16 Dec 2022 11:08:27 -0800 (PST)
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=MvxS2hY2U4GV7GXuATnLLH1KwmY+7CDSDBNYfe1xyUg=; b=G5u7bPijsLvnYFQ4EN5JZ3uaOUYYomhs/0cwoKuC3Ib1wZuwNrSBKV3vZlkBZ9RkDx YdvxBgwB1BB5kmjod15KQ4QGjU6/sZeGm2mHZ9R5Rb7u13FMRK725skUm+hPpR5GkbnY UsdqcAfjMVu6hwotjCeuLapDcKe3ato5nZ9JA1A2kE4BKwwWDGlhqc2hdrSgjTZPD+Y2 0e9GBrm5nHtkZQQ0jA3/ilaBEIB8y2m9SEKr6M9TWAtNgXmSvETqEAtYRlnXTezjXJ/a k+ddZMn4QGVTAijgwYo4vdWnydGIpx6L/NiK5tA9xWEGe5V6Tivvf7QUCHGbguMnLL9h z0MQ==
X-Gm-Message-State: AFqh2kqbWO4reeizpsJAmyJgw9HpLDrQ7Plg4Fi+LfEzKlftPSX3zfJC KN+hspYqwG8iwbwJOBymezxL5RLKRgAKndHk/ZY=
X-Google-Smtp-Source: AMrXdXulr6IQwJdx0gb6qSPlUs4XoNsLL1qmiwgWOh/dnW+XbHx+IteAi9A2LF9dW7J3+/z9wAd/deomE7oVPKnV1JE=
X-Received: by 2002:a5d:668f:0:b0:254:9b64:8aa5 with SMTP id l15-20020a5d668f000000b002549b648aa5mr413357wru.150.1671217696666; Fri, 16 Dec 2022 11:08: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> <CANatvzxeczZqYV_YDH85BTjgGYG510V1Q=8BjOgLEVujE+BKUA@mail.gmail.com> <CAPDSy+41QGms7qzmZHAa=QQzWD8OWZ8VUCbU7am7gqNi3LMPDw@mail.gmail.com>
In-Reply-To: <CAPDSy+41QGms7qzmZHAa=QQzWD8OWZ8VUCbU7am7gqNi3LMPDw@mail.gmail.com>
From: Erik Nygren <erik+ietf@nygren.org>
Date: Fri, 16 Dec 2022 14:08:05 -0500
Message-ID: <CAKC-DJhNeWV4EF7Ghjx_XyEBkXO5y=vhaxV9rKci5Ext49P47g@mail.gmail.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: Kazuho Oku <kazuhooku@gmail.com>, Mark Nottingham <mnot@mnot.net>, Tommy Pauly <tpauly@apple.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="00000000000026faa105eff6b1db"
Received-SPF: pass client-ip=209.85.221.45; envelope-from=nygren@gmail.com; helo=mail-wr1-f45.google.com
X-W3C-Hub-Spam-Status: No, score=-3.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1p6G4K-00Dvq2-09 f59a4c4a9beeebcbfd5e1ced7259fd34
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/CAKC-DJhNeWV4EF7Ghjx_XyEBkXO5y=vhaxV9rKci5Ext49P47g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40656
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>
I also support adoption. The scope seems to be narrowly defined, but giving clients more visibility into this aspect of the endpoint they are connecting to through a proxy does seem worthwhile. On Wed, Dec 14, 2022 at 4:44 PM David Schinazi <dschinazi.ietf@gmail.com> wrote: > I also support adoption, we have a real-world use case for this. > David > > On Tue, Dec 6, 2022 at 4:59 PM Kazuho Oku <kazuhooku@gmail.com> wrote: > >> >> >> 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