Re: [art] Artart last call review of draft-ietf-core-coap-tcp-tls-07

[Patrick McManus <[e-mail]>]

I have a few thoughts on this draft too.

6455-Websockets was a point in time solution for a problem that was solved
later and better by HTTP/2 (RFC 7540) with the introduction of parallelism,
multiplexing, and non 1:1 bi-directional message capabilities (which 6455
only solves 1/3 of).. 6455 is now considered historical and legacy cruft by
many. I don't know of anyone that would think that if 6455 did not exist it
should be introduced into today's ecosystem. (we would still want a
dev-facing interface doing some of the same things as websockets at a js
layer, but it would not be implemented on the wire 6455 style.)

If the motivation of the websockets-coap binding is to deal with
bi-directional problems better than HTTP/1, the answer to me seems to be to
use HTTP/2 (and maybe an extension of the existing http mapping) rather
than building a parallel system of gateways, proxies, and tunnels on top of
6455. It is unfortunate enough (perhaps unavoidable?) that we have a
parallel stack of constrained protocols without building a gatewaying
system between them rooted in legacy baggage.

The draft as much as acknowledges this with some not totally convincing
handwaving (that is not meant pejoratively - I've been known to hand wave
:))

Although HTTP/2 could also potentially address these requirements,
there would be
   additional costs and delays introduced by such a transition.
   Currently, there are also fewer HTTP/2 implementations available for
   constrained devices in comparison to CoAP.

The aspects of the proposed solution that would seem to pose the largest
challenges for constrained devices, (tcp and tls) are also present in
wss:// as well - which begs the question of whether this is designing a
nominally constrained-device ecosystem actually for
not-so-badly-constrained gateways and they should be using our primary
security, application, and transport standards directly. This parallel
stack has to end somewhere, right?

also, if you stay within the semantics of http, but require 7540 or its
successors for reasons of performance, you will pick up quic for free when
we get there - which is just a specific instance of the general argument
with forking standards.

lastly I think the security considerations (both in that section and
elsewhere) could use some work.

The purpose of websockets-6455 is to deploy a mechanism, consistent with
the web security model, for non-privileged javascript to be able to
communicate using communication patterns that do not fit into the HTTP/1
request/reply pattern well. To be consistent with that security model a
websockets end point needs to opt into doing websockets, potentially doing
a particular sub-protocol, and be expecting this request to have been
triggered by a particular Origin.

The net effect is to prohibit random javascript from the web from spraying
around arbitrary TCP streams behind every user agent's firewall, or
otherwise generating arbitrary botnets (beyond what is allowed by SOP
anyhow).

The coap-tcp-tls-websockets forward-proxy model builds an arbitrary gateway
from websockets to coap based on proxy-uri and would seem to run afoul of
the security model by spraying arbitrary coap around instead of arbitrary
tcp :).. Reverse proxy models, being locked down to particular origins,
work better.

(and as a final nit the websocket handshake examples do not have an Origin
request header as required by 6455 for browsers, and I think browsers are
in scope of this document - but thinking and talking about Origin is a key
part of when websockets is and is not appropriate.).

-Patrick



On Wed, May 10, 2017 at 12:31 AM, Carsten Bormann <[e-mail]> wrote:

>
> > On May 9, 2017, at 23:30, Mark Nottingham <[e-mail]> wrote:
> >
> > To close this loop -- the change in -08 isn't sufficiently prominent
> IME; while the general nature of the change is listed in the Abstract, the
> actual normative text is very hard to find.
>
> Certainly, let’s see what the IESG decides here.
>
> > Given that this is a pretty fundamental change in the operation of a URI
> scheme, I'd think it at least deserves its own section, if not a separate
> document.
>
> I don’t agree that this is such a fundamental change here — the
> /.well-known name space in the URI already was special (by the fact that ws
> URIs are mapped to http URIs, which do have /.well-known reserved already).
>
> But that doesn’t matter, we should find the best editorial way to document
> making the well-known URI concept available to WebSocket URIs.
>
> Grüße, Carsten
>
>