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

Kent Watsen <> Fri, 15 May 2020 22:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F53A3A09E9 for <>; Fri, 15 May 2020 15:06:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.647
X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YtO8M4Ik7P0L for <>; Fri, 15 May 2020 15:06:11 -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 9AE6D3A09E8 for <>; Fri, 15 May 2020 15:06:11 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jZiPG-0007UQ-GY for; Fri, 15 May 2020 22:02:14 +0000
Resent-Date: Fri, 15 May 2020 22:02:14 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jZiPE-0007Te-Cm for; Fri, 15 May 2020 22:02:12 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.92) (envelope-from <>) id 1jZiP9-0005Y6-R3 for; Fri, 15 May 2020 22:02:11 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono;; t=1589580116; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=h1nKUY4BSZOCqIx8FrO//zitLtGrYpWm126IMVvZ4wI=; b=BMbUseYXy1ZiRhToL7DkdKtNhtxlmfx3gG02KNHrcFrPGuFAZ2qaw9bXcvn+tqZM fDd/jF/r8EmWbyq6ieCiD1dU5mOIT5XmsKC6xrG32N0tP0RWyeHzJtU1AzCrfQZrWrU gq3qPliSigBUcLfzqVaHI2gGyXYYzk9gSCPCzq+A=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4CD341D5-1AD5-454A-A24D-E491529A6F86"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 15 May 2020 22:01:56 +0000
In-Reply-To: <>
Cc: "" <>
To: HTTP Working Group <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2020.05.15-
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_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1jZiP9-0005Y6-R3 38abba6d52c8ac59eb303980d8ebc4f6
Subject: Re: I-D for a YANG data model to configure HTTP clients and servers
Archived-At: <>
X-Mailing-List: <> archive/latest/37635
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>


I thought that it might be helpful for me to ask a couple specific questions:

1. Supported authentication schemes

My understanding is that there are varying opinions with the schemes listed in the Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry <>.  Partly because some are experimental/historic and partly because some proprietary ones aren’t listed.   Mark impressed upon me before that this draft should try to codify the bare minimum, which I took that to mean just “Basic”, but I’m wondering if there is any harm or even if it would be better, to also support “Digest”?

I’m well aware that both are insecure and require protection from the transport layer, and that Digest really isn’t more secure than Basic but, it seems that they are both pretty much universally supported or, rather, wherever “Basic” is supported, “Digest” seems to be supported also.  Is that in anyway true?

In any case, please be aware the the draft is in no way mandated that any implementation must support any authentication schema.  In YANG terms, the schemes are each individually declared to be supported using a “feature”.  So my question isn’t which schemes must implementations support, but rather which schemes should the standard model make available for implementations to choose to support, knowing that any additional auth schemes (not included in the YANG module) can be “augmented” (another YANG term) in by each implementation per their discretion.   Does that make sense?

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.

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?