[cryptography] Q: CBC in SSH
Hi, From what I can tell from our data, the most common symmetric ciphers in SSH are proposed by client/servers to be used in CBC mode. With SSL/TLS and XMLEnc, this mode has had quite some publicity in the recent past. I was wondering to which degree the attacks that were possible on SSL with AES/CBC might also be applicable to SSH? Quickly asking Google yielded things like http://modular.math.washington.edu/home/wstein/www/home/malb/papers/plaintext_recover_attacks_against_ssh.pdf http://www.kb.cert.org/vuls/id/958563 I was wondering if there have recently been any more insights? Grateful for any pointers. Thanks, Ralph -- Ralph Holz Network Architectures and Services Technische Universität München Phone +49 89 28918043 http://www.net.in.tum.de/de/mitarbeiter/holz/ PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Q: CBC in SSH
Ralph Holz h...@net.in.tum.de writes: From what I can tell from our data, the most common symmetric ciphers in SSH are proposed by client/servers to be used in CBC mode. With SSL/TLS and XMLEnc, this mode has had quite some publicity in the recent past. There have been attacks on SSH based on the fact that portions of the packets aren't authenticated, and as soon as the TLS folks stop bikeshedding and adopt encrypt-then-MAC I'm going to propose the same thing for SSH, it's such a no-brainer it should have been adopted years ago when the first attacks popped up. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Q: CBC in SSH
On Mon, Feb 11, 2013 at 4:45 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: There have been attacks on SSH based on the fact that portions of the packets aren't authenticated, and as soon as the TLS folks stop bikeshedding and adopt encrypt-then-MAC I'm going to propose the same thing for SSH, it's such a no-brainer it should have been adopted years ago when the first attacks popped up. No need, just deprecate the CBC ciphers from SSHv2 and be done. We do have counter-mode replacements. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Q: CBC in SSH
Nico Williams n...@cryptonector.com writes: On Mon, Feb 11, 2013 at 4:45 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: There have been attacks on SSH based on the fact that portions of the packets aren't authenticated, and as soon as the TLS folks stop bikeshedding and adopt encrypt-then-MAC I'm going to propose the same thing for SSH, it's such a no-brainer it should have been adopted years ago when the first attacks popped up. No need, just deprecate the CBC ciphers from SSHv2 and be done. We do have counter-mode replacements. How does counter-mode stop manipulation of the encrypted metadata at the start of the SSH packet, which is what previous attacks have targeted? (And for those who get the reference: Puts out fires, does he?). Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Q: CBC in SSH
On Mon, Feb 11, 2013 at 5:45 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Ralph Holz h...@net.in.tum.de writes: From what I can tell from our data, the most common symmetric ciphers in SSH are proposed by client/servers to be used in CBC mode. With SSL/TLS and XMLEnc, this mode has had quite some publicity in the recent past. There have been attacks on SSH based on the fact that portions of the packets aren't authenticated, and as soon as the TLS folks stop bikeshedding and adopt encrypt-then-MAC I'm going to propose the same thing for SSH, it's such a no-brainer it should have been adopted years ago when the first attacks popped up. Hi Doctor. Out of curiosity, why wait? Krawczyk told us how to do authenticated encryption back in 2001. Confer: The Order of Encryption and Authentication for Protecting Communications (http://www.iacr.org/archive/crypto2001/21390309.pdf). He also said the details of the other schemes were tricky to get right, and history (failures?) has shown he was correct. Wagner and Schneier also told us what should be authenticated back in 1996. Confer: Analysis of the SSL 3.0 Protocol (http://www.schneier.com/paper-ssl.html). Folks are still getting that wrong too. If you use the contrapositive from Wagner and Schneier paper, you can also determine useless protocol fields. I know its nothing new here. I'm just befuddled why standardized protocols written in stone by bright folks (IETF, IEEE, et al) continue to suffer defects that I don't make/endure (because I listen to cryptographers like you). Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Q: CBC in SSH
On Mon, Feb 11, 2013 at 4:57 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Nico Williams n...@cryptonector.com writes: On Mon, Feb 11, 2013 at 4:45 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: There have been attacks on SSH based on the fact that portions of the packets aren't authenticated, and as soon as the TLS folks stop bikeshedding and adopt encrypt-then-MAC I'm going to propose the same thing for SSH, it's such a no-brainer it should have been adopted years ago when the first attacks popped up. No need, just deprecate the CBC ciphers from SSHv2 and be done. We do have counter-mode replacements. How does counter-mode stop manipulation of the encrypted metadata at the start of the SSH packet, which is what previous attacks have targeted? Oh, well, I was thinking of padding -- there's no padding in the counter mode cases, but you're right that we should just always encrypt-then-MAC. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Q: CBC in SSH
Jeffrey Walton noloa...@gmail.com writes: I know its nothing new here. I'm just befuddled why standardized protocols written in stone by bright folks (IETF, IEEE, et al) continue to suffer defects that I don't make/endure (because I listen to cryptographers like you). Well, I'm not really a cryptographer, but I listen to what the actual cryptographers say :-). I don't understand the resistance either, in the case of TLS it's such a trivial change (in my case it was two lines of code added and two lines swapped, alongside hundreds of lines of ad-hockery dealing with MAC-then-encrypt vulnerabilities sidelined) that it was a complete no-brainer. In case anyone's interested, the bikeshedding starts here: http://www.ietf.org/mail-archive/web/tls/current/msg09161.html The full thread is: http://www.ietf.org/mail-archive/web/tls/current/threads.html#09161 We really need a few more cryptographers to weigh in (hint, hint), at the moment the opposition to the change seems to be mostly based on speculation and/or I don't want to change my code. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Q: CBC in SSH
Nico Williams n...@cryptonector.com writes:
I'd go further: this could be the start of the end of the cipher suite
cartesian product nonsense in TLS. Just negotiate {cipher, mode} and key
exchange separately, or possibly cipher, mode, and key exchange, in just the
same way as you propose negotiation of encrypt-then-MAC.
Nonononono, we learned from the IKE mess that the Chinese-menu approach is
vastly worse than the cipher-suite one. TLS has already tried the
Chinese-menu approach to algorithms in TLS 1.2's ECC stuff, and it's at least
as big a mess as IKE was (well, OK, I don't think anything can quite reach the
IKE level, but it's getting there), which is why I had to write this:
http://tools.ietf.org/html/draft-gutmann-tls-eccsuites-03
The problem with the cipher-suite explosion is that people want to throw in
vast numbers of pointless vanity suites and algorithms that no-one will ever
use (to quote Ian Grigg, There is only one cipher suite and that is suite
#1). Even for the ECC draft above, which is an attempt to unravel the mess
created by the Chinese-menu approach, I had requests to add all sorts of
vanity suites with no clear application, but people just wanted them anyway
(I've resisted so far, since the whole intent of the draft is to define a
fixed number of universal-standard suites that everyone supports).
What we really need is a two-way mechanism, a minimal interoperable set of
suites that everything does and then a free-for-all negotiation mechanism that
anyone who wants can implement to their hearts content and everyone else is
free to ignore (I'm a firm believer in you asked for it, you got it design,
if anyone wants the freedom to create a mess built into a standard then they
can take care of it themselves). This is a purely political/fashion problem,
not a technical one.
Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Q: CBC in SSH
On Mon, Feb 11, 2013 at 6:04 PM, Peter Gutmann
pgut...@cs.auckland.ac.nz wrote:
Nico Williams n...@cryptonector.com writes:
I'd go further: this could be the start of the end of the cipher suite
cartesian product nonsense in TLS. Just negotiate {cipher, mode} and key
exchange separately, or possibly cipher, mode, and key exchange, in just the
same way as you propose negotiation of encrypt-then-MAC.
Nonononono, we learned from the IKE mess that the Chinese-menu approach is
vastly worse than the cipher-suite one. TLS has already tried the
Chinese-menu approach to algorithms in TLS 1.2's ECC stuff, and it's at least
as big a mess as IKE was (well, OK, I don't think anything can quite reach the
IKE level, but it's getting there), which is why I had to write this:
SSHv2 has a this approach and it has not been a disaster there.
What's the issue exactly? ECC curve parameters? Something else?
Nico
--
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Q: CBC in SSH
On 02/12/2013 12:04 AM, Peter Gutmann wrote: The problem with the cipher-suite explosion is that people want to throw in vast numbers of pointless vanity suites and algorithms that no-one will ever use On balance I think the ciphersuite approach is slightly better at being a slight counter to inevitable feature/cipher creep. It does at least cause people to pause when they are about to ask for another 96 ciphersuites as happened with certicom. I also agree that only a very very few of the 320 or so TLS ciphersuites are useful. The rest are just a PITA as far as I can see. (Yes, 320. Sigh. [1]) S. [1] http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-3 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Q: CBC in SSH
On Mon, Feb 11, 2013 at 6:23 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 02/12/2013 12:04 AM, Peter Gutmann wrote: The problem with the cipher-suite explosion is that people want to throw in vast numbers of pointless vanity suites and algorithms that no-one will ever use On balance I think the ciphersuite approach is slightly better at being a slight counter to inevitable feature/cipher creep. The ability to give an answer like we can't add your vanity cipher suite because of cartesian explosion seems like a weak justification for the cartesian explosion approach. If we want a policy of limiting what cipher suites we allocate codepoints to then we should have an *explicit* policy, and we should not wimp out when it comes time to enforcing it. But I don't think we have such a policy at the IETF. The IETF policy regarding vanity cipher suites can be described as following some sturm und drang you'll get to have it, but only as OPTIONAL, described in an Informational RFC. Given the de facto policy at the IETF cartesian explosion is just silly -- so much foot self shooting. Let's stop. It does at least cause people to pause when they are about to ask for another 96 ciphersuites as happened with certicom. I also agree that only a very very few of the 320 or so TLS ciphersuites are useful. The rest are just a PITA as far as I can see. (Yes, 320. Sigh. [1]) So how well did cartesian explosion work as an implicit anti-vanity cipher suite policy work then? Not very well, evidently! :) But I suspect that that was not the rationale way, way back when, back when cartesian explosion was selected. The vanity cipher suite disincentive rationalization strikes me as a post-hoc one, and it doesn't work anyways. Please, let's go for an a-la-carte system. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Q: CBC in SSH
On 02/12/2013 12:42 AM, Nico Williams wrote: On Mon, Feb 11, 2013 at 6:23 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 02/12/2013 12:04 AM, Peter Gutmann wrote: The problem with the cipher-suite explosion is that people want to throw in vast numbers of pointless vanity suites and algorithms that no-one will ever use On balance I think the ciphersuite approach is slightly better at being a slight counter to inevitable feature/cipher creep. The ability to give an answer like we can't add your vanity cipher suite because of cartesian explosion seems like a weak justification for the cartesian explosion approach. Yep. (Notice the 2 x slight above:-) If we want a policy of limiting what cipher suites we allocate codepoints to then we should have an *explicit* policy, and we should not wimp out when it comes time to enforcing it. But I don't think we have such a policy at the IETF. Right. And IETF policy is set by IETF participants. If you'd like that to change, I'd say start on the saag list. The IETF policy regarding vanity cipher suites can be described as following some sturm und drang you'll get to have it, but only as OPTIONAL, described in an Informational RFC. Given the de facto policy at the IETF cartesian explosion is just silly -- so much foot self shooting. Let's stop. It does at least cause people to pause when they are about to ask for another 96 ciphersuites as happened with certicom. I also agree that only a very very few of the 320 or so TLS ciphersuites are useful. The rest are just a PITA as far as I can see. (Yes, 320. Sigh. [1]) So how well did cartesian explosion work as an implicit anti-vanity cipher suite policy work then? Not very well, evidently! :) Well, we don't know that. It might have been worse. But I suspect that that was not the rationale way, way back when, back when cartesian explosion was selected. The vanity cipher suite disincentive rationalization strikes me as a post-hoc one, and it doesn't work anyways. Its not a rationalization. I said its slightly less bad not that's why it was done. I wasn't involved in SSL when that decision was made and have had little involvement in TLS at all really. But again, good ideas for helping improve things here would be welcomed. (Oh, but its the IETF, so someone else will also hate that same idea, but that's part of the beauty of going out and meeting folk:-) S. Please, let's go for an a-la-carte system. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Q: CBC in SSH
On Mon, Feb 11, 2013 at 7:00 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 02/12/2013 12:42 AM, Nico Williams wrote: On Mon, Feb 11, 2013 at 6:23 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: But I suspect that that was not the rationale way, way back when, back when cartesian explosion was selected. The vanity cipher suite disincentive rationalization strikes me as a post-hoc one, and it doesn't work anyways. Its not a rationalization. I said its slightly less bad not that's why it was done. I wasn't involved in SSL when that decision was made and have had little involvement in TLS at all really. But it sounds like you (and Peter) are arguing for keeping cartesian explosion on these grounds. We know that didn't work though. And we should absolutely not want to keep some design because it might help (though it doesn't) enforce a policy that we don't have (but some want). Really, if we have no good reason to keep cartesian products for cipher suites then we ought to switch to a la carte (with some reasonable constraints, of course). Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Eating your own dog food
On Mon, Feb 11, 2013 at 8:49 PM, Kevin W. Wall kevin.w.w...@gmail.com wrote: [Full-disclosure: I am not a Bit9 customer; I just get their spam^H^H^H^H, er, informative product emails, thanks to a colleague who signed me up for their mailing list.] ... There were two code signing certificate failures over the past week: Digital certificates and malware: a dangerous mix, http://blog.malwarebytes.org/intelligence/2013/02/digital-certificates-and-malware-a-dangerous-mix/. This one looks like a result of race to the bottom. What no one seems to be questioning in the first place is why Bit9 had a *central* code-signing key used to white-list all the applications in the first place. That pretty much set them up to be a primary target. Their model likely protects their revenue stream. I also wondered about their processes. Is the private key in an HSM? Or is it Sneaker-Net'd to a dedicated machine in an appropriate security boundary when needed? Or is it left online all the time, without a security boundary So am I totally off base here in thinking that Bit9 would have better off requiring that their customers generate their own key pairs? If so, I'd like to know why. Their model likely protects their revenue stream. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Q: CBC in SSH
On Mon, Feb 11, 2013 at 6:20 PM, Peter Gutmann pgut...@cs.auckland.ac.nzwrote: snip ... I don't understand the resistance either, in the case of TLS it's such a trivial change (in my case it was two lines of code added and two lines swapped, alongside hundreds of lines of ad-hockery dealing with MAC-then-encrypt vulnerabilities sidelined) that it was a complete no-brainer. In case anyone's interested, the bikeshedding starts here: http://www.ietf.org/mail-archive/web/tls/current/msg09161.html The full thread is: http://www.ietf.org/mail-archive/web/tls/current/threads.html#09161 We really need a few more cryptographers to weigh in (hint, hint), at the moment the opposition to the change seems to be mostly based on speculation and/or I don't want to change my code. It would be great if we could really get this fixed in TLS 1.3. Then ten years down the road when it finally reaches a critical mass and we can turn off all the previous broken versions, we might actually reach the state where we have a secure communication channel. (Well, that, and if we can do cert pinning, etc. or get rid of all the CAs, but that's a discussion that we've already pummeled cadaverous equines, so lets skip that this time around, okay?) Seriously, I'd like to be optimistic, but looking at this from an industry practitioner's perspective it truly will take us decades to kill off older, insecure versions of SSL / TLS. With some distributions of software, SSLv2 comes still enabled and many browsers in use only still support SSLv3 and TLS 1.0. (And given that WinXP seems to be the Cobol of the OS world, indeed those two may never die as well.) So yeah, by the time TLS 1.3 has reached critical mass that most businesses are willing to disable support for TLS 1.2 and earlier, I'll be looking at retirement. Just sayin'... -kevin -- Blog: http://off-the-wall-security.blogspot.com/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents.-- Nathaniel Borenstein ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
