Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Peter Gutmann <> Tue, 22 March 2016 09:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C741812D63B for <>; Tue, 22 Mar 2016 02:48:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 53tSLZQjHCNs for <>; Tue, 22 Mar 2016 02:48:55 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DFFC12D09A for <>; Tue, 22 Mar 2016 02:48:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1458640134; x=1490176134; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ei+ecJ7RgRHJj2KcU7ZZjuN1qUp8BiGNQizNAowLeX0=; b=EEk9ygpnS4ZXMhOTONUyhGCgwbV5J3rE1We0Yplna6ZIzEELMqM4x6xV Wcj1X0VWmBDL654glwq8V4MFe1ALMgu6ukcdLE/NA9Uc1mCPme050q8HQ ETK3oVI6XwMUtNgoVgW1VjwzxaCHtAdTltDVcbzHPx0lCNy0CMOqoLwX4 dpFfRt49/u9SpUVvkScdcZynUkWnf07baDrUQ1xZp53W38mDFFcZvzz3w Myk1X4x7OG5otkhB1FoBrYBGxsMZ7m8wJEjtcqC1AovI81ZeZgZzrFi18 6JuzKL53JVro8YUeLo85UmtlofY48+8s5w96WTfcIAaIR7auXq8EniduW Q==;
X-IronPort-AV: E=Sophos;i="5.24,376,1454929200"; d="scan'208";a="75752792"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 22 Mar 2016 22:48:52 +1300
Received: from ([]) by ([]) with mapi id 14.03.0266.001; Tue, 22 Mar 2016 22:48:52 +1300
From: Peter Gutmann <>
To: =?iso-8859-1?Q?Joachim_Str=F6mbergson?= <>
Thread-Topic: [TLS] TLS 1.2 Long-term Support Profile draft posted
Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2ev//TwgAgAOYO3D//9JUAIAByROrgAJscYCAAOwz3///L1EAgAI0jb4=
Date: Tue, 22 Mar 2016 09:48:51 +0000
Message-ID: <>
References: <> <> <>, <> <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Mar 2016 09:48:59 -0000

Joachim Strömbergson <> writes:

>When you say that "a Cortex M3 isn't going to be able to handle RSA-2048",
>what do you mean specifically? Considering that it is being done by for
>example SharkSSL [1], is supported by ARM mbed TLS (nee PolarSSL) [2] I fail
>to see what hardware limits you are seeing. Yes, the speed you get is not
>impressive (1-2 seconds to decrypt), but it might be ok, depending on your

It's not just RSA, it's DH as well (looking at the SharkSSL library link it
looks like it doesn't do DH at all, only RSA key transport).  I've seen PLCs
where DHE+RSA leads to handshake times of 10-15s (not an M3, I just use that
as a convenient mental model for an embedded CPU, this was using an industrial
Power SoC), which isn't a good thing when what you're trying to communicate is
an emergency shutdown command.

In these situations, crypto comes at about position 77 in the priority list,
with most of the previous ones taken up by "reliability" and "availability".
If you write a spec that in effect mandates a 15-second delay in communicating
commands to a controller, guess what vendors are going to do?