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

Kent Watsen <> Tue, 19 May 2020 21:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F1F53A1150 for <>; Tue, 19 May 2020 14:00:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Status: No, score=-2.649 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] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5eTGEj_Vl_ps for <>; Tue, 19 May 2020 14:00:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F07C3A0A34 for <>; Tue, 19 May 2020 14:00:49 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jb9Lp-00068r-0I for; Tue, 19 May 2020 21:00:37 +0000
Resent-Date: Tue, 19 May 2020 21:00:37 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jb9Ln-00067o-Mu for; Tue, 19 May 2020 21:00:35 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.92) (envelope-from <>) id 1jb9Ll-00030p-Rx for; Tue, 19 May 2020 21:00:35 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono;; t=1589922022; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=eb3usJgQKd32ncSSA228QlwX+jXm0P1oCHvDM835WLg=; b=VA3EZdHe0YLm/QFdLo7fyTlIMWYjISdugc+8cbMYrqoIJa2xO9iGIIpHyoekREzv E1t2UTMhdk1/NPY25SJ7dPvxi0/JxqDdTGDXcq8TVFlohdDzNQOBnBcln4WfvzF5kAo jya3CM6Ys9FDYOX718/VjOCm7Lvx3S/yLxQCkE3E=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_38CAE5B9-A453-4BEE-B27C-BC9A60E29EF4"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 19 May 2020 21:00:22 +0000
In-Reply-To: <>
Cc: HTTP Working Group <>, "" <>
To: Ben Schwartz <>
References: <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2020.05.19-
Received-SPF: none client-ip=;;
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_H3=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: 1jb9Ll-00030p-Rx b710c979e7cb4fb0bbc83502bca410e4
Subject: Re: I-D for a YANG data model to configure HTTP clients and servers
Archived-At: <>
X-Mailing-List: <> archive/latest/37673
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Ben.

Thanks for CC-ing netconf-chairs, as I’d forgotten to in my follow up...

> 2. Configuring an HTTP client to connect thru a Proxy
> I think that only once in my career, perhaps a couple decades ago, I had to configure a client to connect thru a proxy.   With that in mind, I ask this question as someone that really doesn’t know what the state of the art is.
> My fuzzy-memory is that, connecting thru an HTTP proxy entailed establishing an HTTP connection to a proxy, and that connection is most likely, if not exclusively, on top of TLS (i.e., HTTPS) and mutually authenticated.
> What you're describing is usually called a "Secure Web Proxy”.

Thanks for clarifying my terminology.

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

Sounds exactly like what the current configuration model enables:

	- client MUST use HTTPS (not HTTP)
	- client MUST auth the secure web proxy's TLS cert 
	- client MAY provide TLS-level client certificate
	- client MAY provide one-of-many HTTP client-auth schemes

To be clear, any combination of TLS-level and/or HTTP-level client-auth (including none) is allowed.

Sounds right?

> That is, in order to configure an HTTP(S) client to connect through a proxy, effectively entails configuring it to establish a second HTTP(S) connection.  That is, a first HTTP(S) connection is *to* the proxy, and a second HTTP(S) connection is *thru* the proxy.   Yes?
> Yes, connections through a Secure Web Proxy have end-to-end TLS "inside" the client-proxy TLS.

Thanks for the confirmation.