Subject: [Ace] [ACE] Innovating

From: Göran Selander <[email-masked]>
Date: Fri, 30 Oct 2015 06:59:14 +0000

On 2015-10-29 20:01, "Carsten Bormann" <[email-masked]> wrote:

>Much of the IETF work in the constrained space has been about taking a
>fresh look instead of succumbing to "because its there" (BIT) arguments.
>
>6LoWPAN did not take ROHC, but invented a new header compression
>(twice, throwing out the first one after four years).  It dared to
>make multi-link subnets its standard approach.  It did not just take
>ND, but modified it into 6LoWPAN-ND.
>
>ROLL did not take OSPF or IS-IS, but standardized RPL (and can let a
>thousand flowers bloom there, as e.g. Thread is using RIP).
>
>We didn't take HTTP in CoRE, but designed CoAP, using many of the same
>principles.
>
>But of course many other things were taken as is, because:
>
>-- they do solve the actual problem
>-- they don't bring prohibitive baggage/drawbacks
>and/or
>-- there are substantial network effects from BIT.
>
>You can read more about this approach in
>https://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf
>
>A nice illustration of where we were if we weren't doing that is
>in http://j.mp/gsD4r7
>
>Each time the constrained work entered a new domain (INT, RTG, APP),
>there are these heated arguments about not always using the existing
>hammers.  In Security, BIT arguments are often quite compelling, so
>the threshold is probably higher (I'm sure RTG people will disagree).

Yes, and in ACE we are looking at authentication and authorization, what
are the success stories in security?

Having evaluated quite a few security related candidate patent
applications my experience is that many innovations by laymen fail to be
secure. There are plenty of examples of "innovative" security behind the
headlines of hacked systems. I’m not saying it is impossible to innovate
in the security area, but it is perhaps not as easy as you may think.

CoAP in itself is actually not very convincing in its security design.
CoAP on one hand side outsourced security to DTLS, and on the other hand
defines advanced proxy operations that requires DTLS to be terminated at
the proxy and hence that the proxy is completely trusted (not only with
the proxy operation) unless you use object security. As another example,
using COAP for wireless actuators, a use case which must be considered
central, has serious security issues even with DTLS and without proxies.
(The two subjects of this paragraph are topics for the CORE WG on Friday.)

The security issues with DCAF when reinventing object security for CoAP is
not very reassuring in this respect.

Göran

>
>Oh, and in the development of both 6LoWPAN-ND and CoAP, we have thrown
>out things that had been in the WG document (or even standardized!)
>for over a year or longer when better alternatives came along.  This
>sometimes has been painful, when the old way of doing things already
>had been well-accepted and implemented interoperably.  I hope we can
>do that here, as well.
>
>Grüße, Carsten