[6tisch-security] FW: [Ace] HKDF useage in ace-cose-ecdhe-05

Göran Selander <goran.selander@ericsson.com> Thu, 30 March 2017 06:41 UTC

Return-Path: <goran.selander@ericsson.com>
X-Original-To: 6tisch-security@ietfa.amsl.com
Delivered-To: 6tisch-security@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CF5128768 for <6tisch-security@ietfa.amsl.com>; Wed, 29 Mar 2017 23:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 As6bscseG2Ty for <6tisch-security@ietfa.amsl.com>; Wed, 29 Mar 2017 23:41:05 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437751293E1 for <6tisch-security@ietf.org>; Wed, 29 Mar 2017 23:41:05 -0700 (PDT)
X-AuditID: c1b4fb30-7db199800000628e-87-58dca87f0015
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id EC.1F.25230.F78ACD85; Thu, 30 Mar 2017 08:41:03 +0200 (CEST)
Received: from ESESSMB107.ericsson.se ([169.254.7.125]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0339.000; Thu, 30 Mar 2017 08:41:01 +0200
From: Göran Selander <goran.selander@ericsson.com>
To: 6tisch-security <6tisch-security@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
CC: John Mattsson <john.mattsson@ericsson.com>, Francesca Palombini <francesca.palombini@ericsson.com>, Jim Schaad <ietf@augustcellars.com>
Thread-Topic: [Ace] HKDF useage in ace-cose-ecdhe-05
Thread-Index: AQHSqNcu88JAA4nRTU2MR4Jb7lLaT6Gsd1MAgAAC0wA=
Date: Thu, 30 Mar 2017 06:41:01 +0000
Message-ID: <D50272E5.7AD17%goran.selander@ericsson.com>
References: <9a28d26f-9069-7306-405d-eb7d945c03f0@lounge.org> <D5026B31.7ACD5%goran.selander@ericsson.com>
In-Reply-To: <D5026B31.7ACD5%goran.selander@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.1.161129
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="utf-8"
Content-ID: <7A9E865D0441F64BB7F1B6E9FA0B1DEA@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7pW79ijsRBtv+iVs0r1zEbrF6+nc2 i55D/ewOzB4b50xn81iy5CeTR8ucPcwBzFFcNimpOZllqUX6dglcGa+/z2AteKVRMffPItYG xifqXYycHBICJhJ7tn1nBLGFBNYzSlz4EdLFyAVkL2GU+Pn+FhtIgk3AReJBwyMmEFtEIEai 8WwDC0gRs0Avo0TP6j9gCWEBY4lNi1+yQhSZSNxf/owRwraSuP/9PHMXIwcHi4CqxKOdgSBh XgELiYtfdkAtzpHY+24XI0gJp4ClRNuxSJAwo4CYxPdTa8CmMwuIS9x6Mp8J4mYBiSV7QCaC 2KISLx//A9sqKqAnsfz5Gqi4ksSi25+ZQEYyC2hKrN+lDzHGWmLLxudsELaixJTuh+wQ1whK nJz5hGUCo/gsJNtmIXTPQtI9C0n3LCTdCxhZVzGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIE Rt/BLb8NdjC+fO54iFGAg1GJh/fB3tsRQqyJZcWVuYcYJTiYlUR47RbfiRDiTUmsrEotyo8v Ks1JLT7EKM3BoiTO67jvQoSQQHpiSWp2ampBahFMlomDU6qB0eWWfXVZ0l716vuf57w5qL7M MbXzgGQNt7DePvXPJXE+L/5POBERbueY19cnPOlYzLyHibM8IyNPXFvI2Jwd9nPu31eC96UV E551LI+1XC5uO/3EpCLjo4aRSh7iPJaWa09n53x7aN/ywOSwlMccq3v3tO+zTDrulb1ELE87 d+2hhRVT618zKbEUZyQaajEXFScCAIoa6Ye6AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch-security/KtavYMI48bRLzLW_5aj4KBcaipI>
Subject: [6tisch-security] FW: [Ace] HKDF useage in ace-cose-ecdhe-05
X-BeenThere: 6tisch-security@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch-security>, <mailto:6tisch-security-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch-security/>
List-Post: <mailto:6tisch-security@ietf.org>
List-Help: <mailto:6tisch-security-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch-security>, <mailto:6tisch-security-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Mar 2017 06:41:08 -0000

Hi Michael, 

Thanks for forwarding, please see my answer in the email included below.

Here’s a question for 6tisch-security:

- Do you see any value in encrypting EDHOC message_1 in the symmetric
(PSK) case? That would allow the application to pass encrypted and
integrity protected information in the extension field (EXT_1) already in
the first message.

(For the asymmetric version this is not possible, since there is no shared
key at the time of sending message_1)

Göran


On 2017-03-30 08:30, "Ace on behalf of Göran Selander"
<ace-bounces@ietf.org on behalf of goran.selander@ericsson.com> wrote:

>Hello Dan,
>
>Thanks for commenting.
>
>The encryption of K_1 in the symmetric case is an open issue, we should
>have mentioned that in the meeting. Jim Schaad has also provided arguments
>to remove it.
>
>Your expression “opportunistic” is a good characterisation. We included
>encryption and integrity protection of message_1 in the symmetric version
>mainly because we can, in contrast to in the asymmetric version. But as
>you point out, if we keep encryption of message_1 then we should derive
>K_1 in a different way, and then the key derivation in the asymmetric and
>symmetric versions of the protocol would probably not be the same, which
>was another design objective.
>
>I haven’t talked with my co-authors yet, but we will either omit
>encryption of message_1 in the symmetric case or change the derivation of
>K_1.
>
>Regards,
>Göran
>
>
>On 2017-03-29 23:55, "Ace on behalf of Dan Harkins" <ace-bounces@ietf.org
>on behalf of dharkins@lounge.org> wrote:
>
>>
>>   Hello,
>>
>>   I want to expand on my comments I made at the mic on Monday regarding
>>key derivation with symmetric key authentication in draft-selander-ace-
>>cose-ecdhe-05. When doing authentication with symmetric keys message 1 is
>>encrypted using K_1 and K_1 is generated by passing (as far as I can
>>tell,
>>and I did admit at the mic that it's a little fuzzy) the PSK as salt and
>>an empty key to HKDF. This poses some problems I think.
>>
>>   - The only source of entropy in K_1 is the PSK and this makes the
>>protocol
>>     susceptible to a passive dictionary attack[1] that would,
>>otherwise, not
>>     be possible.
>>
>>   - It seems somewhat unhygienic, from a crypto point of view, to pass
>>     a NULL key to a key derivation function.
>>
>>   - Use of the PSK in messages 2 and 3 authenticate the particular key
>>     used in the AEAD and decryption/verification provides authentication
>>of
>>     the sender to the receiver. But for message 1 is different. There is
>>     no benefit to the key exchange provided by encryption of message 1.
>>
>>   The sole benefit of encrypting in message 1 seems to be that EXT_1
>>gets
>>encrypted. But EXT_1 in the asymmetric case is not encrypted so there
>>doesn't really seem there can be much that needs protection; seems like
>>this is more of an opportunistic thing. That being the case, there is
>>little upside and considerable downside to generating K_1 and encrypting
>>a portion of message 1. I recommend that being removed from the draft.
>>
>>   regards,
>>
>>   Dan.
>>
>>[1] a dictionary attack is defined as one where the attacker gains an
>>advantage from computation as opposed to interaction. The size of the
>>dictionary (e.g. all numbers between 0 and 2^256) only affects the
>>probability of success of the attack not whether it is a dictionary
>>attack or not.
>>
>>
>>
>>
>>_______________________________________________
>>Ace mailing list
>>Ace@ietf.org
>>https://www.ietf.org/mailman/listinfo/ace
>
>_______________________________________________
>Ace mailing list
>Ace@ietf.org
>https://www.ietf.org/mailman/listinfo/ace