Re: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17

Charlie Jacomme <charlie.jacomme@inria.fr> Thu, 03 November 2022 14:00 UTC

Return-Path: <charlie.jacomme@inria.fr>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF612C14F72C for <lake@ietfa.amsl.com>; Thu, 3 Nov 2022 07:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.807
X-Spam-Level:
X-Spam-Status: No, score=-2.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=inria.fr
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dz6OEii2NmUJ for <lake@ietfa.amsl.com>; Thu, 3 Nov 2022 07:00:24 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 822BEC14CE26 for <lake@ietf.org>; Thu, 3 Nov 2022 07:00:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=message-id:date:mime-version:subject:to:references:from: in-reply-to; bh=Dej1Wb9I936QlJDBC3jjb63PCOXSuwIV7DqkfBEfcuE=; b=qZosa8DhgX3HQLVxLn7FGwyXja8g8/vyrjrLwiY5Y0Us7PAsYT3r+c6M WpaX95eeXhvI/HZmyIbBerhtz2yzCzr11nTF18fh+rUCTH6ElV4J7RvNV X5uy9LLK2rMnZoqP7M5t1VntxJgvBWn81DuGQ5jfiYPnggW90YxMSs/+S I=;
Authentication-Results: mail2-relais-roc.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=charlie.jacomme@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr
X-IronPort-AV: E=Sophos; i="5.96,235,1665439200"; d="scan'208,217"; a="72835575"
Received: from lfbn-idf3-1-1093-239.w90-46.abo.wanadoo.fr (HELO [192.168.1.26]) ([90.46.45.239]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Nov 2022 15:00:15 +0100
Content-Type: multipart/alternative; boundary="------------qmmy8JR0actItXmVWnQ1AA5f"
Message-ID: <4d31934f-2a26-3392-8511-934e0dbeeb35@inria.fr>
Date: Thu, 03 Nov 2022 15:00:15 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2
Content-Language: en-US
To: lake@ietf.org
References: <71E133FA-9C4D-4449-BC04-10F6D120D10D@inria.fr>
From: Charlie Jacomme <charlie.jacomme@inria.fr>
In-Reply-To: <71E133FA-9C4D-4449-BC04-10F6D120D10D@inria.fr>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/Jwiuox0Nu46MhG14Qo-BLKx8ezM>
Subject: Re: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Nov 2022 14:00:28 -0000

Hi all,

Following our previous analysis of the draft 12 and 14, we have now 
updated our models w.r.t. draft 17, making a full pass over both the 
protocol changes as well as the security considerations mentioned 
through out the draft.

Overall, there is a last security claim that is slightly wrong from a 
theoretical point of view, but in practice does not bear consequences. 
We detail it bellow. Otherwise, our automated analysis was not able to 
find any other weakness, so we hope that with respect to state of the 
art analysis techniques, the protocol is in a pretty good shape.

It concerns the following point, page 42:
     "Changes in message_1 and message_2 (except PAD_2) are detected 
when verifying Signature_or_MAC_2. "
This claim in fact dependson the security level of the signature scheme 
used. Assume that we have a signature scheme such that given 
"Sign(m,sk)", the signature of message m with secret key sk,  there 
exists a constant "c" such that "Sign(m,sk) XOR c" is also a valid 
signature for the same message m under sk. This is *not*a violation of 
the classical assumption over signatures (EUFCMA), and with such a 
signature scheme, an attacker could then change the content of 
message_2, by xoring the signature part with the constant c, and this 
change would not be detectedafter verifying the signature, and would 
only be caught on a message 4 or key confirmation.

This is only a theoretical attack, relying on the difference between the 
classical cryptographic assumption EUF-CMA, a signature authenticates 
only the underlying message, while underthe stronger SUF-CMAassumption, 
a signature authenticates both the underlying message and the signature 
itself.Noneof the concrete signature scheme currently standardized 
appears to bemalleable under xor. We report it for thoroughness, but are 
uncertain whether the sentence should be changedor not.

Best,
Charlie Jacomme, Elise Klein,Steve KremerandMaïwenn Racouchot.

On 14/10/2022 12:24, Mališa Vučinić wrote:
> Hi all,
>
> As discussed during the interim on 5 October 2022, this email triggers 
> the working group last call for the version 17 of the EDHOC draft, the 
> main item on the agenda of the LAKE working group.
>
> The draft can be found at: 
> https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc/
>
> Please state your position and comments to the list by 4 November 2022 
> so we can discuss them during the IETF 115 meeting in London.
>
> Thanks,
> Mališa, for the chairs
>
>