Re: [Cfrg] [TLS] 3DES diediedie

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sun, 28 August 2016 12:16 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C42512D5F7 for <cfrg@ietfa.amsl.com>; Sun, 28 Aug 2016 05:16:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level:
X-Spam-Status: No, score=-4.748 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.548] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 dWzbTtNdhsoM for <cfrg@ietfa.amsl.com>; Sun, 28 Aug 2016 05:16:18 -0700 (PDT)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3236E12D0FE for <cfrg@irtf.org>; Sun, 28 Aug 2016 05:16:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1472386578; x=1503922578; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IcPZTVF09HKWBmY/W+NjjsXFdmPCsE+3514GuOW0fzA=; b=bG4c/+wBklhQjTtURmXeNsNeq/O5I4T1kvBtXBNSsO+g4xNdxkJkaaCI R6EbgPNspAL6wxZzlkHMzJm+iBhHRCnNjNS3b3DPvdPNYkpvhUrMgVJ5i zypRYcOPnP+eoqFFDYn7zQ9bWCTwXyULnP6kVCEid0nSJulm1r4GCfqnW bPxge6FssCCecn5p1hd1HSOt1R1F9HIX8p/NI6rfiv2P4JRXBzFBIXFoK dfA9ENceTWNZGlmxJKH4HVTzmv4s8jdGruPKU94+D8YOpgE4QVt8ZrHyP DR7vITq7/KFdoXvbTFmYVxhMMJZhtARCHZxAS5fx8ywLOkqKwXDoHkLK4 w==;
X-IronPort-AV: E=Sophos;i="5.28,591,1464609600"; d="scan'208";a="103742998"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Aug 2016 00:16:16 +1200
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Mon, 29 Aug 2016 00:16:16 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
Thread-Topic: [TLS] [Cfrg] 3DES diediedie
Thread-Index: AQHR/8MKtrFGWEVZoU+YIDla8GEE7aBcuoQ1//9++oCAAhKmbg==
Date: Sun, 28 Aug 2016 12:16:16 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4D052A9@uxcn10-5.UoA.auckland.ac.nz>
References: <CAHOTMV+r5PVxqnSozYyqJqq_YocMKV06aAa-43t+5Huzh7Lo=A@mail.gmail.com> <F42128A0-9682-4042-8C7E-E3686743B314@cisco.com> <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz>, <3F61CE56-4F24-4B88-889E-344F11AEB4D5@gmail.com>
In-Reply-To: <3F61CE56-4F24-4B88-889E-344F11AEB4D5@gmail.com>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.6.2.2]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/I4-1F57mr7K7L4VhG4yMcTSBlQI>
Cc: "David McGrew (mcgrew)" <mcgrew@cisco.com>, "cfrg@irtf.org" <cfrg@irtf.org>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [Cfrg] [TLS] 3DES diediedie
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Aug 2016 12:16:19 -0000

Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> writes:

>If every message IoT device sends is a 16 bytes message consisting of one 8
>byte secret and one 8 byte known plaintext, then with a 64-bit cipher, we
>only need roughly 64GB in order to get a meaningful collision (50% chance of
>recovering the secret). The 768GB value we gave was for recovering cookies
>from realistic web browser traffic that could be triggered from JavaScript.

Sure, and I picked the 768GB value because it looks especially unrealistic
:-).  However, for typical SCADA/IoT even a value of 100MB is probably
unrealistic in practice, for the combined reasons that the device just isn't
interesting to attack, it doesn't send enough data to collect lots of it
unless you're prepared to wait a really long time, and, most importantly,
there are a thousand easier ways to get in if you really want to.

Has anyone every seen a SCADA device that stood up to even the smallest amount
of analysis/pen-testing?  I've currently got a rather pricey security
monitoring box sitting here awaiting investigation, and I can pretty much
guarantee I'll find something like unencrypted C&C, calling home to random
addresses overseas, unauthenticated firmware updates, and who knows what else,
just from simple Pineapple or Ettercap check, let alone any kind of active
pen-testing.

So I think it's important to distinguish between a cool demo in the lab and
something an attacker would actually do.  Of all the talks and demos I've seen
of people compromising SCADA and IoT devices, precisely zero even looked at
the crypto, let alone tried to attack it [0].  So if it's something that no-
one bothers attacking because there's always an easier way, it doesn't matter
how strong or weak it is.

As Ian Grigg recently put it:

  The problem we have is not how to get stronger crypto in place, it's how to
  get more crypto in place.

Securing something like MQTT would be a good start...

Peter.

[0] Alongside simply ignoring the fact that crypto may or may not be present,
    I'm also taking things like "fails to check cert issuers" and "allows
    unauthenticated remote firmware updates" as "not looking at the crypto".