[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Killing Algorithms
From:       Peter Gutmann <pgut001 () cs ! auckland ! ac ! nz>
Date:       2015-04-06 13:08:45
Message-ID: 9A043F3CF02CD34C8E74AC1594475C73AAFDBA18 () uxcn10-tdc05 ! UoA ! auckland ! ac ! nz
[Download RAW message or body]

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.

[prev in list] [next in list] [prev in thread] [next in thread]