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

On Fri, May 15, 2020 at 6:06 PM Kent Watsen <kent+ietf@watsen.net> 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
> <https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml>.
> 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
>
>