[cryptography] ciphersuite revocation model? (Re: the spell is broken)
adam at cypherspace.org
Sat Oct 5 07:40:54 EDT 2013
You know part of this problem is the inability to disable dud ciphersuites.
Maybe its time to get pre-emptive on that issue: pair a protocol revocation
cert with a new ciphersuite.
I am reminded of mondex security model: it was a offline respendable
smart-card based ecash system in the UK, with backing of a few large name UK
banks and card issuers, with little wallets like calculators to check a
cards balance. Secure up to tamper resistance or ciphersuite cryptographic
break. Not sure mondex got very far in market penetration beyond a few
trial runs, but the ciphersuite update model is interesting.
So their plan was deploy ciphersuite A, and B in the first card issue. Now
when someone finds a defect in ciphersuite A, issue a revocation cert for
ciphersuite A, and deploy it together with a signed update for ciphersuite
C, that you work on polishing in the background during the life-cycle of A.
Then the cards run on ciphersuite B, with C as the backup. At all times
there is a backup, and at no time do you run on known defective
Now the ciphersuite revocation certs are distributed actually p2p because
mondex is offline respendable. If a card encounters another card that has
heard the news that ciphersuite A is dead, it refuses to use it, and passes
on the signed news.
Maybe to get the update they actually have to go online proper, after a
grace period of running only on ciphersuite B, but thats ok, it'll only
happen once in a few years. Ciphersuite A is pretty instantly disabled as
the news spreads with each payment.
Maybe something like that could work for browser ciphersuites.
It something related to vendor security updates, except there is a prompting
that each site and client you interact with starts warning you the clock is
ticking that you have to disable a ciphersuite. If you persist to ignore it
your browser or server stops working after 6months.
On Sat, Oct 05, 2013 at 02:03:38PM +0300, ianG wrote:
>On 4/10/13 10:52 AM, Peter Gutmann wrote:
>>Jon Callas <jon at callas.org> writes:
>>>In Silent Text, we went far more to the "one true ciphersuite" philosophy. I
>>>think that Iang's writings on that are brilliant.
>>Absolutely. The one downside is that you then need to decide what the OTS is
>>going to be. For example Mozilla (at least via Firefox) seems to think it
>>involves Camellia (!!!?!!?).
>Thanks for those kind words, all. Perhaps some deeper background.
>When I was writing those hypotheses, I was very conscious that there
>was *no silver bullet*. I was trying to extrapolate what we should
>do in a messy world?
>We all know that too many ciphersuites is a mess. We also know that
>only one suite is vulnerable to catastrophic failure, and two or
>three suites is vulnerable to downgrade attacks, bugs in the
>switching, and expansion attacks in committee.
>Perhaps worse, we know that /our work is probably good/ but we are
>too few! We need ways to make cryptoplumbing safe for general
>software engineers, not just us. Not just hand out received wisdom
>like "use TLS" or follow NIST. If we've learnt anything recently, it
>is that standards and NISTs and similar are not always or necessarily
>There are many bad paths. I was trying to figure out what the best
>path among those bad paths was. From theory, I heard no clarity, I
>But in history I found clues, and that is what informs those hypotheses.
>If one looks at the lifecycle of suites (or algorithms, or protocols,
>or products) then one sees that typically, stuff sticks around much
>longer than we want. Suites live way past their sell-by date. Once
>a cryptosystem is in there, it is there to stay until way past
>embarrassing. Old, algorithms, old suites are like senile
>great-aunts, they hang around, part of the family, we can't quite see
>how to push them off, and we justify keeping her for all sorts of
>Alternatively, if one looks at the history of failures, as John
>Kelsey pointed to a few days ago, one sees something surprising:
>rarely is a well-designed, state of the art cryptosuite broken.
>E.g., AES/CBC/HMAC as a suite is now a decade old, and still strong.
>Where things go wrong is typically "outside" the closely designed
>envelope. More, the failures are like an onion: the outside skin is
>the UI, it's tatty before it hits the store. Take the outer layer
>off, and the inner is quite good, but occasionally broken too. If we
>keep peeling off the layers, our design looks better and better....
>Those blemished outer onion layers, those breaks, wherever they are,
>provide the next clue in the puzzle. Not only security issues, but
>we also have many business issues, features, compliance ... all sorts
>of stuff we'd rather ignore.
>E.g., I'm now adding photos to a secure datagram protocol -- oops!
>SSL took over a decade for SNI, coz it was a feature-not-bug.
>Examples abound where we've ignored wider issues because it's SOPs,
>Regardless of what we think or want, if we are really being
>responsible for the end-user result, we would be faced with pressures
>to do wholesale fixes. And these fixes will come more from the
>outside of the onion than from inside. Therefore, I claim:
> The cryptoplumber will be pressured to replace the system
> well before needing to replace any particular crypto component.
>Add in more issues: Resources -- I haven't got a team to spend on
>tweaking. Better knowledge over time -- we know so much more now.
>Incompatibility nightmares. Then, it becomes clearer that the big
>picture is rarely about a cryptosuite, it's about the whole darn
>Hence, I say:
> Plan on replacing the whole lot, when it is needed.
>Which leads to the corollary:
> Do a good job: make it Good as well as True!
>And you likely won't need a second. And another corollary:
> Prepare the next generation in background time.
> In your sleep, on the train, on honeymoon...
> Be advanced, be ready!
>In the rarest of circumstances that you do need to replace a
>cryptosuite, just replace the whole darn lot. It'll be about time,
>>>One True Suite works until that suite is no longer true, and then you're left
>>One way to deal with this that got discussed some time ago over dinner (dining
>>geeks, not cryptographers) is to swap at random among a small number of
>>probably-OK suites and/or algorithms, a sort of probabilistic-security defence
>>against the OTS having a problem. It's not like there's a shortage of them
>>in... well, SSH, SSL/TLS, PGP, S/MIME, etc, anything really.
>For some reason, I'm wondering what the optimal method for a random
>shuffle of dinner choices/plates is, and how the vegetarians are
>going to respond...
>cryptography mailing list
>cryptography at randombit.net
More information about the cryptography