Re: [Ace] Design Consideration Document as one milestone?

[Göran Selander <[e-mail]>]

Hi Hannes

More good comments.

There are two things here:

1. One is to describe how properties of a security protocol impact the
"performance” of constrained devices in scope of this work, and what trade
offs are possible.

2. The other is to list and motivate assumptions and design choices made
in the work to select/profile the security protocol to be made by this
group.

The motivations in 2. should be based on the understanding to the
properties in 1. Whether we need to actually document 1. or not depend on
if we assume that people who will review 2 have this knowledge.


While we cannot optimise the protocol for each given system, I claim that
there is some basic knowledge about constrained devices which may speak
for/against certain protocol candidates.

Maybe we should have tutorials on this too?

I think Klaus’ draft on practical issues with DTLS, although not speaking
about security protocols in general, is a good starting point:
http://tools.ietf.org/id/draft-hartke-dice-practical-issues-00.txt


More comments inline

On 13/03/14 17:05, "Hannes Tschofenig" <[e-mail]> wrote:

>Hi Goeran,
>
>you raise another difficult question that relates a bit to the type of
>IoT devices have in mind. I fully agree with the challenge you
>identified regarding symmetric vs. asymmetric key crypto. It will be
>difficult to reach a consensus on that topic since most people in the
>group are actually not building devices themselves and therefore just
>use what fits their solution best.
>
>The cost of transmission that you mention is also important but the
>implication of just having fewer round-trips is a bit too simplistic
>since a constrained resource server will obviously suffer a lot since he
>has to listen for incoming connection attempts.

Yes, round trips is too simplistic, e.g. size of messages has a large
impact too considering fragmentation. Even “listening" is too simplistic,
since there are various aspects of discontinuous reception, low-power
listening etc. So what can we say? There is expertise on specific
platforms and although there may be differences, my expectation is that
there is some common features like e.g. the cost for communication vs
symmetric crypto in a security protocol.

Göran


>
>So, I fear that (while these are super important aspects) we will have a
>hard time to make any useful decisions about them is two-fold:
>
> * We are not designing complete systems in the IETF and the energy
>assumption relates to the overall system (rather than a single
>protocol). Most of it is outside the IETF protocol design.
>
> * The processing capability obviously depends on the hardware and we
>are not making any statement about hardware in the group. Looking at
>Carsten's presentation from the BOF it also relates to cost, which is
>again a very complicated topic since hardware cost is not the only cost
>in product development.
>
>The classes in the LWIG terminology document do not go into any level of
>details regarding computational power and energy consumption. Only the
>memory requirements are listed in more detail and they seem to be rather
>hand-wavy.
>
>Ciao
>Hannes
>
>
>On 03/13/2014 04:00 PM, Göran Selander wrote:
>> Hi Hannes
>> 
>> Thanks for bringing this up. Let me give some context.
>> 
>> In the preparation for the BOF (and as was later shown in the BOF) it
>>was
>> clear that there are strong opinions about the (in)feasibility of
>>/public
>> key/ crypto in constrained devices. Some people state that ³there will
>> only be two public key operations in the lifetime of this device²,
>> referring to the high cost for asymmetric crypto so that they are only
>> used to establishing secret keys that are used thereafter. Yet other
>> people state ³the cost for public key crypto is negligable in today¹s
>> devices² 
>> 
>> Looking into the literature it is clear that public key crypto is in
>>many
>> cases affordable, but also that it does not come for free. Moreover,
>>when
>> comparing e.g. with message transmission and reception in wireless
>> embedded devices, you get another picture what may be expensive in
>> security protocol execution from an energy consumption point of view.
>> Section 3.2.2 discusses this in a symmetric crypto context.
>> 
>> This draft was put together in a rush a few days before cutoff and
>> contains mainly obvious things. As said, I¹m happy to use this as a
>>basis
>> for a Wiki or restart the discussion. What I would like to see
>>documented
>> is the (non-obvious) cost comparisons  and trade-offs between e.g.
>> round-trips and crypto operations, symmetric vs asymmetric operations
>>etc.
>> to be able to refer to in future discussions when we need to assess the
>> feasibility of a particular security protocol in a constrained
>>environment.
>> 
>> 
>> Göran
>> 
>> 
>> On 13/03/14 02:09, "Hannes Tschofenig" <[e-mail]>
>>wrote:
>> 
>>> Goeran raised a question about adding a milestone for a document that
>>> captures assumptions and design criteria.
>>>
>>> He contributed an initial version of such a document with
>>> https://tools.ietf.org/html/draft-seitz-ace-design-considerations-00
>>>
>>> What does the rest of the group think about that idea?
>>>
>>> Would you be willing to review such a document?
>>> Would you be willing to contribute to such a document?
>>>
>>> Ciao
>>> Hannes
>>>
>> 
>> _______________________________________________
>> Ace mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ace
>> 
>