Subject: [Ace] Innovating

From: Carsten Bormann <[email-masked]>
Date: Fri, 30 Oct 2015 04:01:33 +0900

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

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

---

From: Erik Wahlström neXus <[email-masked]>
Date: Thu, 29 Oct 2015 20:52:17 +0000

I have no interest in throwing away things that’s well accepted and works just because we can. We could equally talk about “if it’s not broke, don’t fix it” here.

Making something new just because it’s fun is not a good thing when it comes to security. Introducing new terminology  and concepts on existing things is not innovative. Limiting the work to symmetric key crypto and only constrained devices is not innovation. Creating an own sphere of protocols that don’t interop with others is not the way forward.

We must help the developers who implement the security for, both big and small, devices and make it super clear and consistant between them all. It’s definitely not a good thing if developers get it wrong when they implement yet another security framework. We should not confuse and bring something new to the table, just because we want to be innovative. 

We should focus our efforts in taking what we have, that we knows scales and works, and can be tied into existing infrastructures and policies, and profile it work for constrained devices.

IETF have been hard at work and been working it's way up the stack and are now, with ace, up in the application layer. That’s where a whole other kind of implementors and developers comes in. That’s developers who don’t care about RPL, IP or 6LoWPAN (a lot of them do and that’s super good) they just want to solve a business problem and reuse what they have. Both knowledge-wise and code-wise. That exactly what we should give them.

/ Erik

> On 29 Oct 2015, at 20:01, Carsten Bormann <[email-masked]> wrote:
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 30 Oct 2015 08:44:38 +0900

> I have no interest in throwing away things that’s well accepted and works just because we can. 

I'm not sure I'm responding to the right thread, because nobody has made
the inverse argument.

But anyway, let's try out that argument.

I have that spool of barbed wire and need to make an Ethernet cable.
I have no interest in throwing away things that’s well accepted and
works just because we can.

Hmm, that didn't work too well.  In particular if I add "Its security
properties have served me well in the past, so I'll make a secure
Ethernet cable out of it."

Let's not discuss this in generalities.  That doesn't work in engineering.

Let me try again.

I have that security protocol called DTLS and need to secure my
communication.  Its security properties have served me well in the past.
 I have no interest in throwing away things that’s well accepted and
works just because we can.

Works much better when discussed in specifics, no?

In the development of CoAP, we selected DTLS as our comsec protocol.
This hasn't been a marriage of love (DTLS 1.2 is not a perfect fit to
the constrained space), but it works.

As I said, in the constrained space I'm very well in favor of
considering throwing away what we have if something clearly better comes
along.  With object security, we aren't there yet, and I'm not sure
we'll ever be there.  But we have to try.

While this is going on, we may always opt to keep multiple tools in our
toolkit.  For CoAP, we selected a set of three DTLS security models;
X.509 for those who already have it, RPK as an innovation (which became
MTI), and PSK as a baseline.  It turns out that PSK works quite well,
beyond what we originally thought, if we just add a little ACE to it.

Grüße, Carsten

---

From: Malisa Vucinic <[email-masked]>
Date: Fri, 30 Oct 2015 01:14:19 +0100

Just to make sure I follow the thread, the definition of innovation brought up here is that in 2015 we should constrain ourselves to PSKs? 

> On 30 Oct 2015, at 00:44, Carsten Bormann <[email-masked]> wrote:
> 
> It turns out that PSK works quite well,

---

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

>we'll ever be there.  But we have to try.

Yes, we had better try because otherwise the use of CoAP requires proxies
to be fully trusted.

For the uninitiated reader: Note that the discussion in ACE is *not* about
DTLS vs object security. Both ACE solution candidates include both
alternatives, although the object security variant in DCAF obviously
doesn’t work. Furthermore DTLS and object security have different security
objectives and can be used together, so it is not a question of throwing
out one and replace with the other.

Göran

---

From: Samuel Erdtman <[email-masked]>
Date: Fri, 30 Oct 2015 08:40:58 +0100

Hi Carsten,

My interpretation of your email is that some times it is preferable to
re-invent and sometimes it is good to reuse. I´m behind you 100% on this.
However if I try to read between the lines in your email it seems like you
are slightly more in favour of re-inventing since thats what your examples
are about, and the linked document seem to further indicate the benefit of
re-inventing and how good that worked out for CoAP. If I have completely
misinterpreted you I´m sorry about that.

So I guess that the question is, should we re-invent or reuse. I think both
can be equally innovative so I don’t think the question should be to
innovate or not, but to re-invent or reuse.

And as you mentioned there are cases when it is right to reuse
“
-- they do solve the actual problem
-- they don't bring prohibitive baggage/drawbacks and/or
-- there are substantial network effects from BIT.
“

Based on this I think we have a case where OAuth2 (and UMA) actually is
very suitable for reuse. It is a protocol that there has gone in a lot of
thinking into to keep them relatively slimed and secure, and as can be seen
in the draft submitted by me, Erik, Hannes, Ludwig and Göran it can with
limited effort be extended to suite the constrained environment. I think
this goes well in line with what Göran indicated in a previous email, when
working with security we need to be very careful to not get things wrong
and to ride on the time spend on validating the correctness of OAuth2 seems
to be a smart thing to do. To put it in a quote “If I have seen further it
is by standing on the shoulders of giants”, Isaac Newton.

I know there was no explicit question in your email but I guess that it was
meant to advocate DCAF over OAuth2. My vote, not surprisingly, goes to
OAuth2 as the most compelling way forward.

Best Regards
Samuel Erdtman

PS.
The past week I have tested out the ides presented in our draft and it
works out very well :-)
DS.

---

From: Stefanie Gerdes <[email-masked]>
Date: Sat, 31 Oct 2015 00:32:06 +0100

Hi all,

The solutions in ACE are all reusing existing solutions, they are just
using different solutions to a different extent.

The use cases show that there is a large variety of scenarios with
different characteristics. The scenarios differ from the web scenarios
which is why we founded ACE in the first place. Some of the use cases
might only require a little tweaking of existing protocols, others need
more consideration about how those protocols can be applied.

We designed DCAF to address scenarios where the client, the server or
both can be class-1 devices (see RFC 7228 [1]), where the client and the
server may belong to different owners with distinct authorization
policies and where these owners may not intervene in the authorization
process at the time of the communication. As far as I understand
draft-seitz-ace-oauth, it only supports less-constrained clients. That
might be fine for the use cases and devices that you have in mind. With
DCAF, we go a bit further into the constrained world and want to enable
constrained devices to securely communicate with other constrained devices.

Of course we want DCAF to interoperate with existing protocols. That is
why we describe how such interactions can work (see
draft-gerdes-ace-dcaf-examples [2]).

Best regards,
Steffi

[1] https://tools.ietf.org/html/rfc7228
[2] https://tools.ietf.org/html/draft-gerdes-ace-dcaf-examples-00

---

From: Stefanie Gerdes <[email-masked]>
Date: Sat, 31 Oct 2015 00:32:30 +0100

Hi Göran,

On 10/30/2015 08:07 AM, Göran Selander wrote:

> the object security variant in DCAF obviously
> doesn’t work. 

I wonder where that is coming from. I may have missed something but your
argument against DCAF-COSE seems to be that we are protecting an option
that you think we shouldn't. However, the discussion about which options
need to be protected how is still going on so I don't understand your
remarks.

All current solutions in ACE are not perfect yet. That's why we call it
"work in progress".

Best regards,
Steffi

---

From: Göran Selander <[email-masked]>
Date: Sat, 31 Oct 2015 06:47:17 +0000

Hi Steffi,

>need to be protected how is still going on so I don't understand your

I don’t know of any discussion about which options needs to be protected,
those are listed in the table in figure 2 of OSCOAP:

https://tools.ietf.org/html/draft-selander-ace-object-security-03#section-6
.2

There is one discussion about how certain option values can be represented
in certain cases to ensure that client and server both can get the same
value. There is a second discussion about how we should protect certain
properties of a CoAP message that can’t be protected today. For example we
need to protect the partitioning of a large message into blocks: There is
no discussion about options block1 and block2 as defined in the blockwise
draft - they can’t be protected because a proxy may split the message in a
block size unknown to client and server. The discussion is about how to
define end-to-end secure block options.

In DCAF-COSE you are protecting a number of options (listed in a previous
mail) which are changed by legitimate CoAP proxy operations. Therefore the
security solution obviously doesn’t work.

>All current solutions in ACE are not perfect yet. That's why we call it

Sure, it is possible that there are errors in OSCOAP that we are not aware
of. The difference is that DCAF-COSE does not solve basic problems with
the security design we solved in OSCOAP before submitting the 00-version a
year ago.

Göran

---

From: Göran Selander <[email-masked]>
Date: Sat, 31 Oct 2015 08:17:06 +0000

On 2015-10-31 00:32, "Stefanie Gerdes" <[email-masked]> wrote:

>draft-seitz-ace-oauth, it only supports less-constrained clients.

No, that is not correct. What gave you that impression? Instead of me
going through how various deployment scenarios in section 6 could be used
with constrained clients, it would be helpful it you gave some reference
to the draft supporting your claim. But just to give an example see
section 6.3:

https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00#section-6.3

In this case the interaction and processing performed by the client could
be restricted to passing a reference token, which can be made arbitrarily
small, to the resource server and then making the resource request. These
two requests could even be combined into one request/response using
optimizations described in Appendix B, see figure 23.

https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00#appendix-B

As one concrete use case the client could be key fob using radio energy
harvesting.

Göran

>That
>constrained devices to securely communicate with other constrained devices
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 31 Oct 2015 11:40:39 +0100

Hi Carsten,

I fully understand your attitude. You are a researcher and you have to
re-write everything from scratch because it attracts students, allows
you to write more publications, and get some additional research
funding. In the adhoc networking, ubiquitous computing, IoT space lots
of researchers have re-created the world many times and most of it just
end up in a trashcan. They got their PhD, received research grants, and
everyone is happy.

Working in a company the story is a bit different. We have things
running and deployed already. We also have a different starting point --
we don't start with a clean slate every 6 months. Just re-writing
everything without a lot of improvement does not find a lot of
excitement. I need to explain to my co-workers (with a straight face)
why I want them to rip out everything. We want to solve problems and so
we spent most of our time understanding the problem domain.

All I am asking for is to
a) understand the state of the art, and
b) try to understand the problems we are solving.

It appears to me too often that in the end the redesign is more at the
level of terminology rather than content. The picture you point us to is
an interesting one because it shows the conflict between the clean slate
research community and the real world. It turns out that there are more
requirements in product design than just technical requirements.

I am not sure what the examples below are really supposed to tell us.
They could tell us that we made the mistake to re-create things from
scratch several times now instead of re-using the existing work and we
still haven't learned anything from it.

Ciao
Hannes

PS: Here is a good presentation from Henning about the lack of
engineering in the research community: http://www.ubioulu.fi/node/296