Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

Eliot Lear <lear@cisco.com> Wed, 27 July 2016 15:06 UTC

Return-Path: <lear@cisco.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA53A12DB17 for <ace@ietfa.amsl.com>; Wed, 27 Jul 2016 08:06:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.807
X-Spam-Level:
X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 tP6AN_bJwp5p for <ace@ietfa.amsl.com>; Wed, 27 Jul 2016 08:06:53 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2465712DB9F for <ace@ietf.org>; Wed, 27 Jul 2016 08:06:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7378; q=dns/txt; s=iport; t=1469632013; x=1470841613; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=m2v2J23ToTvhK0szhVSZnVdNtk/2fdmq5CKJTdLcxRI=; b=S2QvgAo/JTxHWuiMcOyUvaIrjVEKd/iU/640oZadz+tnGOKf28wlZIE9 H9UHeuQwzH89BQ1Re3xji53YwSTMfmPi5L/sGeeHc3ASyoW1DUuRFABqg 24bhaLu4osjCUDJyhfKREPipg8PsJa1MCEiaLSBCWHjoXUp5s0D1atsGF c=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C8CAD9zJhX/xbLJq1dhD+0PYcChh0CgW4RAQEBAQEBAV0nhF0BBAEjClwJAkICAlcGAQwIAQGIJQiRG50gjUoBAQEBAQEBAQEBAQEBAQEBAQEBAQEODogiCIJNh0GCWgEEmTGDOoFwg2qFaIFthFqDDoVrkCU0IIIQHIFOOohyAQEB
X-IronPort-AV: E=Sophos;i="5.28,430,1464652800"; d="asc'?scan'208,217";a="636724075"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2016 15:06:50 +0000
Received: from [10.61.206.72] ([10.61.206.72]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6RF6ocg003593; Wed, 27 Jul 2016 15:06:50 GMT
To: "Grunwald, Markus" <M.Grunwald@osram.com>, "ace@ietf.org" <ace@ietf.org>
References: <4D6B5484A4456C4684818BBF9B04AC2133162422D5@EXC-MCHMBX33.mch.osram.de>
From: Eliot Lear <lear@cisco.com>
Message-ID: <1d8bee6a-4893-5e25-3028-93f6ab3c17cd@cisco.com>
Date: Wed, 27 Jul 2016 17:06:49 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <4D6B5484A4456C4684818BBF9B04AC2133162422D5@EXC-MCHMBX33.mch.osram.de>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="rCvQfIrd6g7Qu9NhgSG68UVHG3Xx5gwF6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/-yILoMx5b0_Qyq4XvD3WGE8SCao>
Subject: Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 27 Jul 2016 15:06:55 -0000

Markus,

Thanks for this.  I think you've summed up the problem in a nut shell. 
Please see below.


On 7/27/16 2:34 PM, Grunwald, Markus wrote:

>  
>
> For me, this leads to multiple security levels:
>
> 1)      Basic security: fast response, low cost with lower security:
> use symmetric keys. Use this where the risk is low.
>
> 2)      High security, low cost: Allow slow(er) response times,
> because of the ECC calculations. Kind of a compromise…
>
> 3)      High security, higher cost: add some crypto hardware. For high
> risk environments with low latency
>
>  
>
> I don’t think that we will be able to cover the whole range of
> requirements with one single approach. Implementing the lowest level
> would be relatively easy for first concepts.
>
>

And here is the challenge: enterprise networks do have a variety of risk
tolerances from minimal to high security.  What is being designed here
is a protocol that needs to accommodate a broad range of those uses.  It
seems to me that we need to be cognizant of the broader picture in order
to solve for (1), (2), and (3).  If we can be assured of some
infrastructure support at lower layers,  we can at least answer the
question of who did what when.  And that is important.

Regards,

Eliot