Re: [TLS] Killing Algorithms
Peter Gutmann <pgut001@cs.auckland.ac.nz> Mon, 06 April 2015 13:08 UTC
Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CAC1A8868 for <tls@ietfa.amsl.com>; Mon, 6 Apr 2015 06:08:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.51
X-Spam-Level:
X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 46x0e0P_FSnA for <tls@ietfa.amsl.com>; Mon, 6 Apr 2015 06:08:48 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D6761A870A for <tls@ietf.org>; Mon, 6 Apr 2015 06:08:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1428325728; x=1459861728; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=F8YuUCHq/Syyhi0THnGAcZaruGx1Q6RXvQWxyIzXzBk=; b=s7Tp0CWgl4m3/uDJTo3fUvBT13Oj5rlLg6MUU7OL5bTwNHUqa/5LOu3R LyB3/dOmvaI54EtfIdEjsswMx1J66Q3Nq26VHfmRiNuX8OmjzovEetOL8 KZWDqCvVeWwfx0ZE0bTi2GhNGanEK4NuqUO+HYtZ83HqNgobGKTWJLr59 s=;
X-IronPort-AV: E=Sophos;i="5.11,531,1422874800"; d="scan'208";a="319105118"
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 mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 07 Apr 2015 01:08:46 +1200
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.245]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Tue, 7 Apr 2015 01:08:45 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Killing Algorithms
Thread-Index: AdBwatAk2Nmcoo9ATBKVIweLTsO3Xg==
Date: Mon, 06 Apr 2015 13:08:45 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFDBA18@uxcn10-tdc05.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/hLHeoAIXwEOyozpa71XN4GXiKUc>
Subject: Re: [TLS] Killing Algorithms
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 06 Apr 2015 13:08:49 -0000
Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes: >Suppose the TLS WG (or some other part of the IETF or IRTF) places a >"believed good until" date on every algorithm in the spec. We would commit >to updating this "freshness" estimate some interval before the algorithm >"expires". We would ask implementations with access to a "real" clock to >commit to disabling each algorithm after its expiration date, unless they >recieve notice that the algorithm's expiration has been extended. The first thing you'd need to do there is add an explicit exception for embedded devices/SCADA. The algorithm replacement policy there is "when the hardware fails", typically 10-15 years away minimum. Once something is deployed, you never touch anything that might trigger a failure of some kind, ever. There are devices out there still using single DES, and that's perfectly all right because it's secure enough for what they do. Sure, an attacker could spend tends of thousands of dollars on a custom-built FPGA DES- breaker and carry out some high-tech attack to bypass network security controls and mess with a power substation, but the same would be achieved much more cheaply by slipping some random guy a bag of weed to throw a bike chain over a HV feeder. >Some problems i have this proposal (i'm sure there are others too!): One not on your list, and one of my favourites: * Your device receives a message authenticated with algorithm A saying "Algorithm B is broken, don't use it", and a message authenticated with algorithm B saying "Algorithm A is broken, don't use it". There's also the delightful prospect of embedded control engineers drawing lots to see who has to flip the break-things switch. Perhaps someone who's due to retire shortly anyway. >I'd love to hear other concrete proposals for how we can actually effectively >deprecate algorithms in the wild, once a deployed base exists. For SCADA, you choose a good enough algorithm (and by "good enough" I mean good enough for practical use, not good enough for academics), and you stick with it. So there is a de facto way of dealing with this issue, it's "wait for the hardware to die". Peter.
- [TLS] Killing Algorithms Bill Frantz
- Re: [TLS] Killing Algorithms Peter Yee
- Re: [TLS] Killing Algorithms Salz, Rich
- Re: [TLS] Killing Algorithms Aaron Zauner
- Re: [TLS] Killing Algorithms Daniel Kahn Gillmor
- Re: [TLS] Killing Algorithms Richard Moore
- Re: [TLS] Killing Algorithms Peter Gutmann
- Re: [TLS] Killing Algorithms Bill Frantz
- Re: [TLS] Killing Algorithms Benjamin Kaduk