Re: [core] New version of draft-amsuess-core-transport-indication

[Christian Amsüss <[e-mail]>]

On Sun, Jul 11, 2021 at 10:23:43PM +0200, Carsten Bormann wrote:
> How important is it for a node to know whether the proxy offered
> actually is on-origin (not really a proxy)?

On Sun, Jul 11, 2021 at 05:57:36PM -0400, Michael Richardson wrote:
> I think that sometimes a thing that's really a forward proxy doesn't really
> need/want to confuse clients with this concept.

"clients need not make the distinction at all" between same-host and any
other proxies. I've introduced the same-host proxy terminology to make
it easier to grasp how little a server needs to do to become a proxy for
itself.

If that's confusing for the client side, it may need reevaluation in the
way it is written.

> I’m trying to think up how one would set up security (DTLS, OSCORE) to
> that proxy. Somehow, 2.2 leaves me a bit hungry here (credentials may
> need to be mutual).

Mutual credentials are something I have not considered; it's easy for
same-host proxies, but an actual proxy would need quite some setup for
that.

With OSCORE, all the security aspects should be simple and
straightforward (except when a proxy wants an *additional* security
context on its own, for which a document is upcoming AFAICT).

With (D)TLS, a proxy is necessarily trusted, so on its server-side it
needs either a way to have a good-for-the-upstream-server certificate
(which it could probably obtain even at run time), or a very powerful
certificate ("Trust The Proxy. The Proxy is Mother, the Proxy is
Father"), which sounds like an aweful thing and maybe shouldn't be
condoned at all. (Like, if you can get such a certificate, instead get
an ACME account and pull an origin certificate on demand; this is *not*
about same-host proxies any more anyway).

Mutual (D)TLS authentication through a proxy is even hairier, as again
the proxy would need an "I Am All The Clients" certifciate.

But well, in a world with (D)TLS and proxies, if you want both then the
proxy *does* become ~"by its very nature a man-in-the-middle" (7252 section
11.2 citing 2616 section 15.7).

> Obviously, knowing that something “is a proxy” doesn’t mean the client
> can suddenly assume it is less-constrained (e.g., with respect to
> achievable response-rates and fan-in/fan-outs), power-affluent etc.  

Yes -- particularly when it is a suitable proxy only for a particular
origin.

> Maybe those semantics go beyond what we would want to indicate via
> web-linking, but I think we should think more about how to make them
> available for server/proxy  selection.

A lot of things could be said about a proxy ("I support FASOR and am
close to your origin server, pick me for performance." -- "I have ample
cache content, join the hive."); link target attributes can do a lot
here, but I'd rather not specify anything here without a very good idea
on how they would be used in practice.

(For simple administrative information for human consumption,
<program-and-version>;rel=impl-info;anchor="the-proxy" would do)


Possibly (considering both the hard questions on different-host proxies
regarding security, and the distinction question), it'd benefit the
document to treat third party proxy services more as an afterthought.
Then, the security parts could be made stricter ("Just because it's
through a proxy doesn't mean you can compromise on security"). Third
party proxies would stay easy where OSCORE/EDHOC is used, and (D)TLS
deployments need to go all the way with whichever tools are available
there. (In which I do have little experience, never having deployed with
them).

BR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom