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

Joachim Strömbergson <joachim@secworks.se> Tue, 22 March 2016 10:05 UTC

Return-Path: <joachim@secworks.se>
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 0F74212D52B for <tls@ietfa.amsl.com>; Tue, 22 Mar 2016 03:05:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 nx-Jwlg6yf-L for <tls@ietfa.amsl.com>; Tue, 22 Mar 2016 03:05:00 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC00B12D09A for <tls@ietf.org>; Tue, 22 Mar 2016 03:04:59 -0700 (PDT)
Received: from Knubbis.local (unknown [80.252.219.34]) by mail.frobbit.se (Postfix) with ESMTPSA id 672D821465; Tue, 22 Mar 2016 11:04:57 +0100 (CET)
Message-ID: <56F118C7.1010203@secworks.se>
Date: Tue, 22 Mar 2016 11:04:55 +0100
From: =?ISO-8859-1?Q?Joachim_Str=F6mbergson?= <joachim@secworks.se>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <1561199.VzgNuqeJQW@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4C26CD5@uxcn10-tdc05.UoA.auckland.ac.nz>, <7261615.38m5dF3AYF@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4C28640@uxcn10-tdc05.UoA.auckland.ac.nz>, <56EFF22C.5040505@secworks.se> <9A043F3CF02CD34C8E74AC1594475C73F4C29500@uxcn10-tdc05.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C29500@uxcn10-tdc05.UoA.auckland.ac.nz>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/lmqsFrxOzWGJKl8adi1PL36Dwzc>
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:05:02 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Aloha!

Peter Gutmann wrote:
> 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?

They are going to do the handshake once every day (or even less) and
keep the session alive. Or use session resumption. Based on what I've
seen in PLCs you normally don't start a new session for every single
command. YMMV.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          joachim@secworks.se
========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJW8RjHAAoJEF3cfFQkIuyNVTEP/ip7HWyE6MROHjT1OhDHnYa2
R+dcW4nW8cf6BzCg3SmQl5ldB4Fw5t6m/htySDzmSMgGSAnXO9XaFaALHrKHQKc5
csI00gWz6bO+LXRgsFnXD5z7lcEAu6NJ6IPMR9z1ueUXIzZoRUkE1o4G4zUmAgjR
nNITn9HRmPyeysKiYPHwkHrQTQTf1kBgdp7yfvLPu0j8WQUOhzxLPk1S/9pbRgI6
9CnpngVNf4aRBRzqmRDQwtNsSswNP7xRwEVvjObfzXqOME7CZsxegEN/wNDPkx5H
Gp7J1Q/l5zUBW7wRXHJdlmq2vlUc6B4kJMC1deZDLA0sNM+3BNVN1SEaroW9TMDj
GdEjdVO6MImBgrLBpOlpgHoD/FRXJXENv+QR8AQMFbUejkP3gcyb0xtz2PTC79xl
Qvr2pwCCStr8QIoWVaDTF9ia8CCPtZpVEZ0Zl8B91QqQ0+7tSoDqUy84JA0m3kMN
rskv70CREq48U8yvPDh7EWbd9eOIz8jIiy7dMSAYprNdeZ0K5QMZe+iZbpz70Djn
vZd5vyBySxMeKHqvf8BV0H2hx6gU0Y+RC/A+DQ69ieBicdzpb2BZrgpW/rFrM+TA
3L+3nKOIvL3xZ7xhlAayj7bbvaN6NloSH2OG246Zus4UAPZTzifKYEPQ3ogEC7VQ
L37kW5FIZxmdAgzi2eTs
=eO/5
-----END PGP SIGNATURE-----