[cryptography] ciphersuite revocation model? (Re: the spell is broken)

Adam Back 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.
>A conundrum!
>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 
>the answer.
>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 
>saw noise.
>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 
>inane reasons.
>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 mailing list