Subject: [TLS] Killing Algorithms

From: Bill Frantz <[email-masked]>
Date: Thu, 2 Apr 2015 17:37:50 -0700

There has been discussion stating that having at least two 
algorithms for each function allows algorithms to be turned off 
when weaknesses are discovered. There needs to be a way to 
actually implement this decision.

At a minimum, the security considerations section should mention 
this requirement. Perhaps saying something like this:

History has shown that all of the algorithms SSL/TLS depended on 
20 years ago have been shown to have weaknesses and as a result, 
they are no longer included in TLS 1.3. There is no reason to 
believe that the algorithms required for TLS 1.3 won't share 
their fate. TLS 1.3 requires at least 2 algorithms for each 
security function so failing algorithms can be turned off. Each 
implementation of TLS MUST have a technique for effectively 
turning algorithms off.

-----------

 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.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        |Security, like correctness, is| Periwinkle
(408)356-8506      |not an add-on feature. - Attr-| 16345 
Englewood Ave
www.pwpconsult.com |ibuted to Andrew Tanenbaum    | Los Gatos, 
CA 95032

---

From: "Peter Yee" <[email-masked]>
Date: Thu, 2 Apr 2015 18:12:51 -0700

I don't think killing off algorithms has been a problem of not having a
means to do so.  Rather, I suspect it's a question of inertia.  It takes a
really catastrophic failure or wide news coverage of a new attack to move
server admins away from a configuration that "has been working fine up until
now."  Breaking someone's fielded server setup with a special message is not
going to be a popular feature.  Enterprises are a conservative lot when it
comes to changing things.

		-Peter

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Bill Frantz
Sent: Thursday, April 02, 2015 5:38 PM
To: [email-masked]
Subject: [TLS] Killing Algorithms

-----------

Cheers - Bill

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 3 Apr 2015 14:56:18 +0000

> Each implementation of TLS MUST have a technique for effectively turning
> algorithms off.

This is a no-op; the implementation's method can be "rebuild and re-install all dependant software" or "keep your licenses current and download the latest updates from your vendor"

I understand the sentiment, but I don't want to put "noise" requirements into the RFC.

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 03 Apr 2015 17:21:43 +0200

Hi,

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.

Aaron

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 03 Apr 2015 17:01:00 -0400

> 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

---

From: Richard Moore <[email-masked]>
Date: Sat, 4 Apr 2015 00:54:37 +0100

>     what happens to these machines?
This problem already exists since you need the time to validate the
certificate.

Overall though, I'm not in favour of having a set cut off date except
perhaps for ciphers we already know are weak, however since the idea is to
design a new version of TLS why would things that are known to be weak be
included in the first place?

Rich.

---

From: Bill Frantz <[email-masked]>
Date: Mon, 6 Apr 2015 19:56:12 -0700

On 4/3/15 at 7:56 AM, [email-masked] (Salz, Rich) wrote:

>This is a no-op; the implementation's method can be "rebuild 
>and re-install all dependant software" or "keep your licenses 
>current and download the latest updates from your vendor"

It is not quite a NOP. I am willing to agree that everyone 
reading this list understands the need. What I want is something 
an auditor can point to and say, unless you have a way to remove 
unsafe crypto from the application, you are not TLS standard 
compliant. I want people who come to the standard for guidance 
to learn that the current state of the art in crypto isn't permanent.

It is hard to find the argument that we need several of each 
type of algorithm in case security problems are found with one 
if we can't turn it off. My immediate reaction is that having 
only one of each type of algorithm would be much better because 
it would eliminate a complex part of TLS, algorithm negotiation. 
(Further reflection says that that approach might make version 
negotiation harder. But single algorithm TLS might still be a win.)

On 4/6/15 at 6:08 AM, [email-masked] (Peter Gutmann) wrote:

>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".

This approach worries me. Even though SCADA applications don't 
need secrecy anywhere near as much as they need authentication, 
the authentication data they are working off can go very stale 
in the 10-20 year lifespan of industrial equipment. Heck, (I 
know some industrial equipment which is over 100 years old and 
still in use. Fortunately, it doesn't have any crypto 
components.) At a minimum, I would want to be able to update the 
trust anchors a lot more frequently. Keys can be stolen, and 
nation state actors, who might want to sabotage industrial 
equipment, have a long history of successfully stealing keys.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"We used to quip that "password" is the most common
408-356-8506       | password. Now it's 'password1.' Who said 
users haven't
www.pwpconsult.com | learned anything about security?" -- Bruce Schneier