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

From: Christian Amsüss <[email-masked]>
Date: Sat, 10 Jul 2021 21:16:20 +0200

Hello CoRE,

I've submitted a new version of transport-indication, which sets out to
be a solution to the different-protocols situation we're having.

Please have a look at the document, which should be pretty
self-explanatory by now and includes several remarks on contentiuous
points.

Feedback on-list before the IETF would be much appreciated; at latest, I
hope to get a chance to discuss this during the session.

BR
Christian

> Date: Sat, 10 Jul 2021 12:07:38 -0700
> Name:		draft-amsuess-core-transport-indication
> Revision:	01
> Title:		CoAP Protocol Indication
> Document date:	2021-07-10
> Group:		Individual Submission
> Pages:		20
> URL:            https://www.ietf.org/archive/id/draft-amsuess-core-transport-indication-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-amsuess-core-transport-indication/
> Html:           https://www.ietf.org/archive/id/draft-amsuess-core-transport-indication-01.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-amsuess-core-transport-indication
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-amsuess-core-transport-indication-01
> 
> Abstract:
>    The Constrained Application Protocol (CoAP, [RFC7252]) is available
>    over different transports (UDP, DTLS, TCP, TLS, WebSockets), but
>    lacks a way to unify these addresses.  This document provides
>    terminology based on Web Linking [RFC8288] to express alternative
>    transports available to a device, and to optimize exchanges using
>    these.

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

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 11 Jul 2021 22:23:43 +0200

Interesting.  I did a fast skim (more before 111), and my brain got going in two directions:

How important is it for a node to know whether the proxy offered actually is on-origin (not really a proxy)?  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).

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

Nit:
mechsnisms
but In general
the HTTP provisions the Alt-Svc
separte

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sun, 11 Jul 2021 17:57:36 -0400

{I browsed the document even more quickly yesterday}

Carsten Bormann <[email-masked]> wrote:
    > How important is it for a node to know whether the proxy offered
    > actually is on-origin (not really a proxy)?  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).

I agree.
I think that sometimes a thing that's really a forward proxy doesn't really
need/want to confuse clients with this concept.

This does, in general, raise questions about identities, and I think that
actually we need to take this into our thoughts.

(D)TLS gives us subcerts as a tool.
EDHOC lets us do security through the proxy.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 12 Jul 2021 10:17:24 +0200

On Sun, Jul 11, 2021 at 10:23:43PM +0200, Carsten Bormann wrote:
> actually is on-origin (not really a proxy)?

> 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