Subject: [Cfrg] Re: [saag] status of SSL vs SHA-1/MD-5, etc.?

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 16 Oct 2005 09:46:12 -0400

In message <[email-masked]>, Alex Alten write
s:
>Everyone,
>
>So where do we stand with secure networking protocols vs SHA-1/MD-5?
>
>Is SSL at risk? Is TLS OK (because of HMAC)?
>
>SSH, IPSec, etc?
>

The major risk that I know of is for signed objects, which generally 
means signed email, i.e., S/MIME and PGP.  MD5 absolutely should not be 
used for email, period.  The current attack on SHA-1 is probably 
infeasible for most attackers; that said, it would be better to have 
something stronger.  We'll know more about that in two weeks, after 
NIST's Hash Function Workshop.  As I mentioned on the cryptography list 
-- did you really have to post your query to all three lists? -- a few 
days ago, NSA rated SHA-384 as suitable for Top Secret traffic, though 
I'll note that the authenticity of a message rarely has the long-term 
need for security as does confidentiality.  

As Eric Rescorla and I showed, though, none of the network protocols 
are ready for deployment of a new hash function.  That is, newer 
versions of OpenSSL support may SHA-256, but there's no way to 
negotiate such usage if you don't know the status of the system to 
which you're talking.  

My own estimate is that it will take 4-8 years before everything just 
works: 1 year for the IETF to standardize negotiation mechanisms, 1-2 
years for design, code, and test by vendors, and 2-5 years for 
deployment by the user community -- note that most machines are *never* 
upgrade, only replaced.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: Alex Alten <[email-masked]>
Date: Sun, 16 Oct 2005 00:00:40 -0700

Everyone,

SSH, IPSec, etc?

- Alex
--

- Alex Alten

---

From: Ben Laurie <[email-masked]>
Date: Sun, 16 Oct 2005 17:07:22 +0100

> negotiate such usage if you don't know the status of the system to 

None of the ones you looked at you mean - your survey wasn't comprehensive.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 16 Oct 2005 14:24:55 -0400

>None of the ones you looked at you mean - your survey wasn't comprehensive.
No, it wasn't comprehensive, but we looked at the major IETF protocols.

---

From: Ian G <[email-masked]>
Date: Sun, 16 Oct 2005 17:05:40 +0100

> So where do we stand with secure networking protocols vs SHA-1/MD-5?

Wait until the Halloween Bash, and then another
year or two before it all settles out.  In the
meantime the work that has to be done is to
prepare all the protocols to be able to handle
multiple hashes (something I posted on a while
ago here, and I gather that Eric and Steven have
written up in more detail in a paper).

Even if you decide to replace the hashes now,
you still have to do all the above work anyway,
so it makes sense to do the work, then select
the hash as late as possible.

> Is SSL at risk?

No, not from that.  To quote from Adi's laws,
Cryptography is typically bypassed, not penetrated.
(I would say he was being conservative, to any
measurable degree it is always bypassed, never
penetrated.)

> Is TLS OK (because of HMAC)?

There is a rollback attack in SSL which needs
to be fixed, but the real fix - turn off SSL
v2 - is hard because it can only be done at
the app level at the moment.  (It's a big flaw
in "secure" browsing.  Mozilla has been testing
and moving towards turning off v2 in its browser
for 6 months now so as to help phishing.)

So, yes, turn off SSL v2 wherever and whenever
you can and move to TLS.  Do it in your servers
and browsers.

> SSH, IPSec, etc?

By far the biggest risk is that crypto protocols
aren't deployed because of complexity.  A change
to hashes increases complexity, so a priori it
will probably reduce security more than it
improves it.  Hence the strategy above, to
move hashes in so that they can migrate without
effecting the rest of the protocol.

Just some comments!

iang