Re: [Ace] Coordinated effort to produce updated profiles for the use of crypto algorithms in IoT

"Panos Kampanakis (pkampana)" <> Mon, 19 March 2018 13:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3924F124BFA for <>; Mon, 19 Mar 2018 06:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.529
X-Spam-Status: No, score=-14.529 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3Hlfk5kVY2Ui for <>; Mon, 19 Mar 2018 06:34:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 16A831242F5 for <>; Mon, 19 Mar 2018 06:34:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=15414; q=dns/txt; s=iport; t=1521466492; x=1522676092; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=hJhfqxkCg+r5GEI5kDrKFEsGyiLUVV+3SavdHYuYGMM=; b=RfMzsmjMPZ3DWobvrauJMCCtiaOqQ+rKjlZvjP2t2pIIXyjg03PyUkeq /u73Umr+VHUAeEyVxaTi8je7T73A8emRvHECJd60HfMJKDqy6JQB3RHFP oWRTx1ZGDwSZ8SJeDJML+whI81vy/6MS+wJEIQOL5n8erl0ZtdVw3DFa0 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.48,330,1517875200"; d="scan'208,217"; a="86154181"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Mar 2018 13:34:51 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w2JDYorg001328 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Mar 2018 13:34:50 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 19 Mar 2018 08:34:49 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Mon, 19 Mar 2018 08:34:49 -0500
From: "Panos Kampanakis (pkampana)" <>
To: Hannes Tschofenig <>, John Mattsson <>, "" <>
Thread-Topic: Coordinated effort to produce updated profiles for the use of crypto algorithms in IoT
Thread-Index: AQHTv3MCif9BXYu3HkOEVFgP17NpK6PXZ6pAgAAm4cA=
Date: Mon, 19 Mar 2018 13:34:49 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_aeb821b3a89a43a4aa865e39f94d3b0eXCHALN010ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Ace] Coordinated effort to produce updated profiles for the use of crypto algorithms in IoT
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Mar 2018 13:34:54 -0000

Should consider analysis and recommendations by NIST’s LWC project too

From: Ace [] On Behalf Of Hannes Tschofenig
Sent: Monday, March 19, 2018 7:15 AM
To: John Mattsson <>;
Subject: Re: [Ace] Coordinated effort to produce updated profiles for the use of crypto algorithms in IoT

Here is a relevant document:

From: Ace [] On Behalf Of John Mattsson
Sent: 19 March 2018 11:11
Subject: [Ace] Coordinated effort to produce updated profiles for the use of crypto algorithms in IoT

I strongly support Carsten’s suggestion to have a coordinated effort to produce updated profiles for the use of crypto algorithms in IoT. I think the work should include at least TLS, DTLS, COSE, and X.509 and take into consideration the hardware acceleration available in (future) devices. Should also look if there is a need to update X.509 profile in RFC 7925, any new IoT profile should be applicable to both TLS and COSE.

How do we get this started in a way that applies to all IETF groups using crypto? I would be happy to help with this work.

Some quick thoughts:

- Curve25519 is already implemented a lot, but needs to be differentiated from Ed25519 which is not implemented as much (yet) and may require CA support for certificate based deployments. Curve25519 and Ed25519 has a strong potential to lower latency, storage, memory, and battery consumptions in IoT devices. There was earlier vendors stating that curves with a cofactor caused problems for older hardware. My understanding is that this has now changed, at least the UICC vendors in 3GPP has stated that curve25519 works on their current hardware.

- ChaCha20-Poly1305 is only standardized with 128-bit tags and therefore not very well suited for IoT. Like GCM, Poly1305 is not very well suited for truncated tags. AES_128_OCB_8 only requires half the amount of AES operations, but AES is not drawing much power compared to transmitting, listening, and receiving radio, so any update from AES_128_CCM_8 might not be worth it. I think 64 bit tags is a good compromised between overhead and security for IoT.

-  PRF. TLS 1.3 used HMAC with SHA-256, RFC8247 specifies PRF_AES128_XCBC for devices not having SHA.

- Hash algorithms, Ed25519 is as far as I known standardized with SHA-512/256. IoT deployments of TLS and DTLS typically use SHA-256.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.