Should we create some kind of CRL style protocol for algorithms? Then we'd have a bunch of servers run by various organizations specialized on crypto/computer security that can issue warnings against unsecure algorithms, as well as cipher modes and combinations of ciphers and whatever else it might be. And your client software would "subscribe" to a bunch of those servers.
There should probably be degrees to the warnings, since a cipher can be totally broken in one set of circumstances but still work perfectly fine in others. Switching when its not needed can be costly. I think I'd prefer if this was OS level and all your local software could use it. I think a problem can be that there doesn't seem to be a universal naming convention for ciphers or ciphersuites in software configurations. We'd have to define one that clients can understand. - Sent from my phone Den 5 okt 2013 13:41 skrev "Adam Back" <a...@cypherspace.org>: > 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 > ciphersuites. > > 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. > Adam > > On Sat, Oct 05, 2013 at 02:03:38PM +0300, ianG wrote: > >> On 4/10/13 10:52 AM, Peter Gutmann wrote: >> >>> Jon Callas <j...@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, Someone-Else's-Problem. >> >> 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 system. >> >> >> >> 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, anyway. >> >> >> >> One True Suite works until that suite is no longer true, and then you're >>>> left >>>> hanging. >>>> >>> >>> 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... >> >> >> >> iang >> ______________________________**_________________ >> cryptography mailing list >> cryptography@randombit.net >> http://lists.randombit.net/**mailman/listinfo/cryptography<http://lists.randombit.net/mailman/listinfo/cryptography> >> > ______________________________**_________________ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/**mailman/listinfo/cryptography<http://lists.randombit.net/mailman/listinfo/cryptography> >
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
