Re: [TLS] Killing Algorithms

[Daniel Kahn Gillmor <[e-mail]>]

On Fri 2015-04-03 11:21:43 -0400, Aaron Zauner wrote:
> Bill Frantz wrote:
>> From my point of view, acceptable techniques include online code update
>> and special messages which cause implementations to permanently cease
>> using an algorithm, along with methods and procedures to ensure that
>> these techniques actually work in the field.
>
> As much as I like the idea, until someone proposes a sane method to do
> so /online/ in the protocol, I don't think it makes a lot of sense to
> add that to the document, it'll only confuse readers.
>
> I can't think of a way a client or server could negotiate that a cipher
> is deprecated. That'll cause downgrade attacks all over again, possibly
> to the cipher that would by then be deprecated.

I've thought about this a lot, and haven't come up with any answers that
i like very much.  Perhaps i'm not imaginative or accepting enough,
though!

The problem is even worse than "we don't have a good way to switch an
algorithm off when we learn that it's broken" -- at the moment we don't
even have a good way to switch an algorithm off when we have known for
years that it has been catastrophically broken (e.g. EXPORT ciphersuites
still biting people in 2015, thanks FREAK)!

At the moment, the only deprecation models we have seen in practice are:

 0) explicit deprecation documents from standards bodies (like we've
    done for SSLv2 and are doing for RC4).  These often don't have
    teeth, but are used as advice.

 1) phased approaches driven by powerful vendors (e.g. SHA-1 deprecation
    driven by Google and Microsoft) that rely on gradually-increasing
    minor "penalties" (log messages, UI deprecation hints, no EV
    decoration, etc) with a well-published timeline for outright banning
    of the algorithm.  These approaches only seem possible only for
    those players with a lot of weight to throw around.


Here's a thought experiment to consider (i don't think i like this any
more than either of the above, but i haven't heard any other proposals):

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.

This would put an upper bound on algorithm lifetime, as well as on the
lifetime that a given implementation could survive in the wild without
at least some form of update mechanism (for updating the algorithm
expiration dates at least).

This also provides an impetus for the community to do active, regular
review, rather than assuming that a given algorithm is just "good until
proven otherwise".

Some problems i have this proposal (i'm sure there are others too!):

  * smells like "planned obsolescence" -- from a "consumer" perspective,
    it feels manipulative and cagey, esp. if i have to pay my vendor for
    the upgrades.  Do we need to start thinking about software less like
    a hammer or saw, and more like fruits and vegetables?

  * not every implementation has a wall clock, or has it set right.
    what happens to these machines?

  * what happens when the update mechanism fails?

  * what kinds of attacks do we introduce by being able to turn off
    algorithms by fiddling with a victim's clock?

  * who is responsible for refreshing the expiration dates?  how is this
    done?  this is a time-sensitive, potentially-controversial topic.
    What if the deadline passes without being able to establish a rough
    consensus?  what if the relevant parties fall asleep at the switch?

  * what does this do to the incentives in the academic community to
    study algorithms that have not yet reached their expiration date?
    what about algorithms past their expiration date?

I'd love to hear other concrete proposals for how we can actually
effectively deprecate algorithms in the wild, once a deployed base
exists.

    --dkg