[cryptography] ciphersuite revocation model? (Re: the spell is broken)
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,
Re: [cryptography] ciphersuite revocation model? (Re: the spell is broken)
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
Re: [cryptography] ciphersuite revocation model? (Re: the spell is broken)
On Sat, Oct 05, 2013 at 02:29:11PM +0200, Natanael wrote: 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. Just make sure you sign your protocol revocation message using more than one protocol... Speaking of as a last ditch measure you can two messages that hash to the same digest as a type of revocation message. -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
