Re: I-D for a YANG data model to configure HTTP clients and servers

Kent Watsen <kent+ietf@watsen.net> Wed, 20 May 2020 16:45 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 8C1A43A0C01 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 20 May 2020 09:45:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Level:
X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWWV_ijUp5V8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 20 May 2020 09:45:08 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2CE53A0C00 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 20 May 2020 09:45:08 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jbRnZ-000180-37 for ietf-http-wg-dist@listhub.w3.org; Wed, 20 May 2020 16:42:29 +0000
Resent-Date: Wed, 20 May 2020 16:42:29 +0000
Resent-Message-Id: <E1jbRnZ-000180-37@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <0100017232f6c672-757ca22c-c2bf-4ebe-ab32-5a7d365520e3-000000@amazonses.watsen.net>) id 1jbRnX-00017E-Cd for ietf-http-wg@listhub.w3.org; Wed, 20 May 2020 16:42:27 +0000
Received: from a48-95.smtp-out.amazonses.com ([54.240.48.95]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.92) (envelope-from <0100017232f6c672-757ca22c-c2bf-4ebe-ab32-5a7d365520e3-000000@amazonses.watsen.net>) id 1jbRnU-0003cX-G0 for ietf-http-wg@w3.org; Wed, 20 May 2020 16:42:27 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1589992933; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=JzcHMhq7qP+IhPm/VpyKqeUPfGqb1c7MsQq8NLrXlYs=; b=YmSm7wZCPAmf0FrZMRq7J0PLBRxekovM0JLE3wZ+arkAYjUAqkgZ4wJNnRn/3Xfs o9OgxoDoenLCaPk1ZUcrF75WG7vkuXEmpVMLycwiFlO2h8tB+4B0xH92L05F68irL+K z/ltD5bbuSq8n3icM+CTiWIX5l9b9IFJ9Fbjk+JY=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100017232f6c672-757ca22c-c2bf-4ebe-ab32-5a7d365520e3-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_ADC9346D-A317-41E6-8DE5-B5623F2C3E59"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 20 May 2020 16:42:13 +0000
In-Reply-To: <CAHbrMsBgPLsBGs143bt9irPck7rxLbW9x5NntDK4HT97pcSS2w@mail.gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>
To: Ben Schwartz <bemasc@google.com>
References: <01000171e5dd76ed-e0bb6d02-faa5-4672-93ab-74bc96ae9775-000000@email.amazonses.com> <CC4173EC-67BB-4652-885E-4C50564CB05A@mnot.net> <01000171eaff2503-d978e760-f03b-416b-9208-f9a95d1ecadb-000000@email.amazonses.com> <41183D9D-6287-416D-B160-F67E0B40916C@mnot.net> <0100017205194aed-7b540ec1-10ac-4d1e-b66b-682f321c3e99-000000@email.amazonses.com> <20200512034441.GC4623@1wt.eu> <010001720a7abfc7-775d8708-8a88-4d8a-bf8d-cff51a02c1b2-000000@email.amazonses.com> <010001721a5bb104-2c64f226-b46f-40a8-8ca7-2298e3ed3811-000000@email.amazonses.com> <CAHbrMsAh=LsB0wwjW0DK3vc5eAfKJZOE6NEFb2P=UkeV4Y8kxg@mail.gmail.com> <010001722ebcc4ef-2c6b91a9-f736-443d-ab22-1629b8187145-000000@email.amazonses.com> <CAHbrMsBgPLsBGs143bt9irPck7rxLbW9x5NntDK4HT97pcSS2w@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2020.05.20-54.240.48.95
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Received-SPF: none client-ip=54.240.48.95; envelope-from=0100017232f6c672-757ca22c-c2bf-4ebe-ab32-5a7d365520e3-000000@amazonses.watsen.net; helo=a48-95.smtp-out.amazonses.com
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1jbRnU-0003cX-G0 ee2df4b58229ba396c5bb0a51b06d08f
X-Original-To: ietf-http-wg@w3.org
Subject: Re: I-D for a YANG data model to configure HTTP clients and servers
Archived-At: <https://www.w3.org/mid/0100017232f6c672-757ca22c-c2bf-4ebe-ab32-5a7d365520e3-000000@email.amazonses.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37683
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>

Hi Ben,

Thank you for your previous response.  I spent some time reading up on proxies.  A few comments below.


>> What you're describing is usually called a "Secure Web Proxy”.
> 
> Thanks for clarifying my terminology.

Actually, it seems that “HTTPS Proxy” is equally used, perhaps more so…

Additionally, it seems “HTTP Proxy” (without the ’S’) is also a thing…would this be just a “Web Proxy” using your nomenclature?


>> It is a popular type of proxy but far from the only one.
> 
> I don’t understand this comment, especially in context of the next comment…
> 
> 
>> The client always  authenticates the server name (in the usual way with TLS), but servers might or might not require clients to authenticate, and might do so in many different ways.
> 
> 
> This comment was in reference to a Secure Web Proxy.  When using a SOCKS5 proxy, in contrast, there is typically no use of TLS between client and proxy (although there will still be end-to-end TLS if the proxied connection is for HTTPS).

Here’s my current understanding:
   - it's a lot to review, but I’d be incredibly grateful if you could try...


SOCKS4
Very common today still
Client connects to proxy using TCP
Client can send any TCP-based protocol through the proxy, not just HTTP(S)
Ref: "SOCKS", Proceedings: 1992 Usenix Security Symposium.

SOCKS4a
Extends SOCKS4 to enable client to specific a domain name rather than an IP address
A non-standard SSH-originated term for when the proxy resolves the URL hostname 
Ref: https://www.openssh.com/txt/socks4a.protocol

SOCKS5
Builds on top of SOCK4a to add support for UDP and authentication
Notably does NOT enable TLS-connect to the proxy (e.g., to protect the auth)
For UDP, client first connects to proxy via TCP in order to obtain an allocated UDP port to make a subsequent connection to
Various auth mechanisms supported (inc. cleartext username/password) 
Ref: https://tools.ietf.org/html/rfc1928

SOCK5h
A non-standard CURL-specific term for when the proxy resolves the URL hostname
Not an extension of RFC 1928, so much as a CLI-disambiguator
Ref: https://curl.haxx.se/libcurl/c/CURLOPT_PROXY.html

Web Proxy / HTTP Proxy
Client connects to proxy via TCP
Client sends HTTP request to destination webserver
If the “http” scheme is used, then proxy connects to destination server using TCP
If the “https” scheme is used, then proxy connects to destination server using TLS
Proxy MAY auth the destination TLS server’s EE cert
e.g., CURL’s “--ca-cert” parameter 
Proxy MAY send a client-cert to destination TLS server
e.g., CURL’s “--key” and “--cert” parameters still work
HTTP-level auth to the proxy NEVER required?
HTTP-level auth to the destination HTTP server MAY be required
Ref: https://tools.ietf.org/html/rfc7230

Secure Web Proxy / HTTPS Proxy
Same as above with only the following difference:
OLD
Client connects to proxy via TCP
NEW
Client connects to proxy via TLS
Client auths proxy’s EE cert
e.g., CURL’s “--proxy-cacert” parameter
TLS-level client-auth to proxy MAY be required
e.g., CURL’s "--proxy-cert” parameter
SRP-level client-auth MAY be required?
e.g., CURL’s “—tlsauthtype” parameter


PS: It’s also possible for an HTTP client to first connect to a SOCKS server, and then connect to a HTTP(S) Proxy thru the SOCKS server, in order to reach a destination web server (e.g.,CURL’s "--preproxy” parameter).

Kent