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

Ben Schwartz <> Sat, 16 May 2020 21:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDA433A0949 for <>; Sat, 16 May 2020 14:21:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.349
X-Spam-Status: No, score=-8.349 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OSBvsmMd_9HN for <>; Sat, 16 May 2020 14:21:03 -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 0C78E3A0942 for <>; Sat, 16 May 2020 14:21:02 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1ja4Bz-0001AR-HU for; Sat, 16 May 2020 21:17:59 +0000
Resent-Date: Sat, 16 May 2020 21:17:59 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1ja4Bx-00019f-SC for; Sat, 16 May 2020 21:17:57 +0000
Received: from ([2a00:1450:4864:20::429]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1ja4Bv-0001nn-Fa for; Sat, 16 May 2020 21:17:57 +0000
Received: by with SMTP id h17so7391449wrc.8 for <>; Sat, 16 May 2020 14:17:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3ybeo9jzqVjEcwyanGt12AnWUFDyXAEkcywcAbhtt4g=; b=X+kXsHDOLbN9iPuj41qmk8aLTzqT7eeTr5oimDCQcuBTD+aPyq5hbI+jRdvZZofhu7 7glkjdlfP4l2mwGTW4ABCGdrxQSUVi4hb/W2/cJSi1VuiCVn8gPsPDgxQWrI/1cRmgGj RoqwDZSomerBA1mnFuBXB6iOjqG4XH2LEFNAsewzGhdb8wbYVAJAMYhYuXMsErWuhjYP JB4lFHk1G1kzMz9RPtQw6ZeI2IGNR/GPNSL59hF18YtSH5GYvptg83b/6F9wZ3+32bRe fIWryRVVR2DjMBUh4rUX0ryjHqlPYPROBLRBrydCGTTuqD210IAoAOR1y8u5R2xpHYwu MCtg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3ybeo9jzqVjEcwyanGt12AnWUFDyXAEkcywcAbhtt4g=; b=L5KsgLRTYCJfc419F/8LJBousfXW+8d9I/fIDxIzoF5HyFfpqYsvb/LahpqTEfN51j Xr7zUoK+0NSZTcCHTEQd0R7CnZzYXU7FKcyK9zYzpgDejf8mCYMlSVSzkM0NhJz0nD0B 5ytT0bk5QIUvajvbW3KjHZAFqbc2HwUy/P5iACPcsea3+mvDU15CscP/vABgxCBdUZVH JuNC8/emm9sHVM1HaAVfPWdD+7QrkS7/HpqKjUEkzQtmW59QRKDLgq4EpoPU2Ih0FWlr 4ieJOoVOXfh/Zj+cABcJoFZZC+QOAxXEgw/7nbL8sNpGpfs0WLZEzCTQfdRlxRBUzD1/ ZK/Q==
X-Gm-Message-State: AOAM533NMpJTFts3OYwG7muVDSQpQWaEtnGcfV1RVmGsSwjZd+I6uEYk t9bOUxwKfqLBiYWS+j3Qpaq25CwVA4gQinQbxRJbCg==
X-Google-Smtp-Source: ABdhPJxfA3wOK8ZuVgNfmPDbQghHDQ5nsX1seEaHPhFa6zWPqYN+NEcRds91WWhSi6YBJiAGZrT7AJ8697G2yUSXJ6k=
X-Received: by 2002:adf:814a:: with SMTP id 68mr11387413wrm.177.1589663863559; Sat, 16 May 2020 14:17:43 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Sat, 16 May 2020 17:17:31 -0400
Message-ID: <>
To: Kent Watsen <>
Cc: HTTP Working Group <>, "" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000efcd1205a5ca75b7"
Received-SPF: pass client-ip=2a00:1450:4864:20::429;;
X-W3C-Hub-Spam-Status: No, score=-20.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1ja4Bv-0001nn-Fa cbbf99312566d443749d6745d5323814
Subject: Re: I-D for a YANG data model to configure HTTP clients and servers
Archived-At: <>
X-Mailing-List: <> archive/latest/37640
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Fri, May 15, 2020 at 6:06 PM Kent Watsen <> wrote:

> Dear HTTP WG,
> 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.

What you're describing is usually called a "Secure Web Proxy".  It is a
popular type of proxy but far from the only one.  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.

> 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!
> Kent