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

Göran Selander <goran.selander@ericsson.com> Thu, 13 March 2014 15:01 UTC

Return-Path: <goran.selander@ericsson.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D851A09E0 for <ace@ietfa.amsl.com>; Thu, 13 Mar 2014 08:01:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0EwR4z7dew7 for <ace@ietfa.amsl.com>; Thu, 13 Mar 2014 08:01:03 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3A92F1A09DA for <ace@ietf.org>; Thu, 13 Mar 2014 08:01:03 -0700 (PDT)
X-AuditID: c1b4fb25-b7f038e000005d01-89-5321c827c66d
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F3.F1.23809.728C1235; Thu, 13 Mar 2014 16:00:55 +0100 (CET)
Received: from ESESSMB303.ericsson.se ([169.254.3.152]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0387.000; Thu, 13 Mar 2014 16:00:55 +0100
From: Göran Selander <goran.selander@ericsson.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] Design Consideration Document as one milestone?
Thread-Index: AQHPPrewRMKjLCAMGkyGQgBzpjAjyZrfHJ+A
Date: Thu, 13 Mar 2014 15:00:55 +0000
Message-ID: <CF477EB6.B3F8%goran.selander@ericsson.com>
References: <53210566.60100@gmx.net>
In-Reply-To: <53210566.60100@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <CE6CB9EFB8590A4FBFBC485017E2A21B@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvja76CcVggxcLrS2+f+thtli68x6r A5PH4k372TyWLPnJFMAUxWWTkpqTWZZapG+XwJXx4FcDY8F0gYqlmz8yNjDO4O1i5OCQEDCR +PrBoouRE8gUk7hwbz1bFyMXh5DAIUaJJ7ObWCGcJYwSz793MIJUsQm4Shx48I4JxBYRCJI4 3PiaDcQWFnCSWPt+NjtE3Fli8cEljBC2kcTDy+dYQJaxCKhKzJnCDBLmFTCXuNE5lR0kLCSg IvHnFFiYE6ji8vePYJ2MQPd8P7UGbBOzgLjErSfzmSDuFJBYsuc8M4QtKvHy8T9WEFtUQE/i 3qO5LBBxJYlFtz9D9epJ3Jg6hQ3CtpZ4e7+BHcLWlli28DXUOYISJ2c+YZnAKD4LybpZSNpn IWmfhaR9FpL2BYysqxjZcxMzc9LLjTYxAuPp4JbfqjsY75wTOcQozcGiJM774a1zkJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQZGpu15efbeW8KKOH/82MLH5nfir5iE1HZlvhd3qw9JGWnb HNC9/3DzCsGftm8uyxbGtL/kNNT2UHixh7v5Xuutta1LNZ7cdazrFHaZ/GD2ImnNuT9TnvqH cxZbNq0USLlXF6UXsdD31L2yE50uzR9uauySa43xEdj1ZsJsrgPTrdt5fS4bbmJRYinOSDTU Yi4qTgQAFkiYZ3UCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/0kjYzOD3Uq4DC4iTfN32xtAYQPA
Subject: Re: [Ace] Design Consideration Document as one milestone?
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Mar 2014 15:01:05 -0000

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" <hannes.tschofenig@gmx.net> 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
>