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

Hubert Kario <hkario@redhat.com> Tue, 22 March 2016 10:48 UTC

Return-Path: <hkario@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BDA12D6B1 for <tls@ietfa.amsl.com>; Tue, 22 Mar 2016 03:48:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Level:
X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 4aNK6YaR3fiS for <tls@ietfa.amsl.com>; Tue, 22 Mar 2016 03:48:21 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B83412D101 for <tls@ietf.org>; Tue, 22 Mar 2016 03:42:31 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id A6D1D3DD; Tue, 22 Mar 2016 10:42:30 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-113.brq.redhat.com [10.34.0.113]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2MAgT4l018020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Mar 2016 06:42:30 -0400
From: Hubert Kario <hkario@redhat.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Date: Tue, 22 Mar 2016 11:42:23 +0100
Message-ID: <15689268.cdSCJdr7cB@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.10 (Linux/4.4.5-200.fc22.x86_64; KDE/4.14.17; x86_64; ; )
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C29500@uxcn10-tdc05.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <56EFF22C.5040505@secworks.se> <9A043F3CF02CD34C8E74AC1594475C73F4C29500@uxcn10-tdc05.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2494083.S12pyfxVKd"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/tpCJVWjjR9xyPM2bYKkufgsxxJo>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2016 10:48:22 -0000

On Tuesday 22 March 2016 09:48:51 Peter Gutmann wrote:
> Joachim Strömbergson <joachim@secworks.se>; 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 application.
> 
> 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?

attacks only get better

if the hardware can't do crypto securely now, it certainly won't be able 
to do it tomorrow (you know, in the "Long Term")

it's a waste of time to patch up attacks that are still largely 
theoretical if you leave a mile wide hole in the fence
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic