Subject: [Ipsec] Re: [saag] Structure of documents discussing protocols and hashes

From: Paul Hoffman <[email-masked]>
Date: Mon, 5 Dec 2005 14:53:59 -0800

At 9:52 PM +0200 12/5/05, Hugo Krawczyk wrote:
>My view is that there is no need to RUSH into upgrading SHA-1 in
>IKEv1 or v2. The only place where the recent attacks have a direct
>relevance is in public key certificates. Other uses of hashes in IKE
>(which include PRF, MAC, ephemeral signatures, and the randomness
>extraction functionality referred to by David's mail) would have some
>benefit from a hash function upgrade but nothing truly urgent. None of
>these uses are based on collision resistance in some essential way.
>Of course, new attacks, in particular on the pseudo-random properties of
>secretly-keyed HMAC, could be found in the future (or maybe even in the
>present), but such attacks to be of real significance will not be merely
>collision attacks.

The series of "hash evaluation" documents should give as specific 
numbers as possible.

Here, you say "there is no need to RUSH" and "nothing truly urgent". 
Do we know of any collision-reduction attacks now that would cause 
any issues with IKE or IPsec? If not, why is there any need to amble, 
much less rush, towards new hash functions?

Given that our preferred encryption algorithms are 112 and 128 bits 
strong, exactly where should we worry  about using MD5 or SHA1 in 
IPsec (other than in the PKIX part)? Of course, if someone uses 
AES-192 or AES-256, they probably want to use SHA-256, but that's not 
relevant here.

>First, we do not know how fast
>attacks will improve and reach the point of being relevant even for uses
>such as in IKE.

Let's assume that the collision-resistance attacks get very good very 
quickly, such as reducing the collision-resistance of SHA-1 to 40 
bits, but the preimage resistance is unaffected. Would our 
recommended hash functions change, and why?

--Paul Hoffman, Director
--VPN Consortium

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

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 05 Dec 2005 18:19:34 -0500

>much less rush, towards new hash functions?

Per mine and ekr's paper, the problem is that we *can't* switch, even 
if a serious problem developed.  What's really necessary now is to add 
the extra signaling, so that we can switch hash functions if and when 
that becomes necessary.

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 5 Dec 2005 16:05:43 -0800

>the extra signaling, so that we can switch hash functions if and when

That is important, but orthogonal to my question for Hugo.

--Paul Hoffman, Director
--VPN Consortium

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 8 Dec 2005 21:04:57 +0200 (IST)

See below

> much less rush, towards new hash functions?

Even if the functions we use today are not yet broken in a practical
sense, what is broken is our confidence on these functions, and we have to
act on this "broken confidence".  The way to do it is NOT by trying to
measure (quantify) every day what is the latest best attack, but rather we
should take advantage of the fact that most applications are currently NOT
broken and prepare for a calm (but firm!) transition to new functions.
In this sense I am not suggesting anything different than Belovin-Rescorla.

> the extra signaling, so that we can switch hash functions if and when

The counter-part of this switching problem is (paraphrasing the above):
"even when we'll be ready to switch we won't know to WHAT to switch".
That is, do not expect that we will be in a situation where our
confidence will be fully (or even significantly) recovered. But that is
not necessarily a bad thing. Thinking of specific cryptographic functions
as resistant to attacks for many years to come is an illusion. We must
always be ready for cryptanalytical developments as we've seen with
MD5/SHA or even more serious ones (i.e., ones that develop more rapidly
into practical attacks).

What can we do about this state of affairs? Preparing our applications and
implementations for switchable functions, building our protocols on the
basis of functionality rather than on specific algorithms (for example,
define the protocol in terms of mac or prf instead of HMAC, and certainly
not in terms of specific functions such as SHA2) and BUILD YOUR
SECURITY/CRYPTO DESIGNS ON THE MINIMAL POSSIBLE ASSUMPTIONS ON THE
UNDERLYING FUNCTIONS.

HMAC's design  is a good example of applying the latter principle
and the reason HMAC has resisted all the recent attacks. Should we
apply this principle again? Sure. Randomized hashing is the name of the
(new) game when it comes to collision resistant hashing and signatures.

Hugo

> strong, exactly where should we worryabout using MD5 or SHA1 in

---

From: Stephen Kent <[email-masked]>
Date: Thu, 8 Dec 2005 15:10:52 -0500

Hugo,

I think it would be good to explore randomized hashing in the near 
term (said the non-cryptographer).  At a minimum it might be good to 
develop RH-based integrity options for our various protocols, and see 
what the performance and engineering implications are.  Would you 
envision using an hash algorithm like SHA-256 with randomization as a 
pre-processing step?  That might be an especially attractive approach 
for an interim hash function solution, given that NIST is likely to 
suggest a near term transition to SHA-256.

Steve

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Dec 2005 16:47:01 -0500

>>>>> "Hugo" == Hugo Krawczyk <[email-masked]> writes:
    Hugo> different than Belovin-Rescorla.  As Steve has recently put
    Hugo> it:

    smb> Per mine and ekr's paper, the problem is that we *can't* switch,
    smb> even if a serious problem developed.  What's really necessary now
    smb> is to add the extra signaling, so that we can switch hash
    smb> functions if and when that becomes necessary.

    Hugo> The counter-part of this switching problem is (paraphrasing
    Hugo> the above): "even when we'll be ready to switch we won't know
    Hugo> to WHAT to switch".  That is, do not expect that we will be in
    Hugo> a situation where our confidence will be fully (or even

  My feeling is: pick something. SHA-256 is fine as a test case for
testing the ability to switch.  It might not be the right answer in
2010.

  I also continue to question if PRF uses are really affected.

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Dec 2005 15:02:19 -0800

At 3:02 PM -0500 12/8/05, Sam Hartman wrote:
>We'd like to have quantified results to guide our thinking.  We don't
>have such results; we have educated intuition about the strengths of
>functions we are using.

We have both. We now have quantified results that tell us that the 
two popular hash functions have much-weaker-than-expected 
collision-resistance. We have another related quantified result: the 
initial attacks on these functions were improved on in less than a 
year. We have educated intuition that these attacks will probably get 
better.

>I think it would be irresponsible to ignore
>this intuition just as I think it irresponsible to panic.

Fully agree. But I don't see how the intuition affects the structure 
of of documents discussing protocols and hashes.

- Our desire for agility in choosing all cryptographic functions to 
use is based on solid quantified understanding that sometimes a 
devastating attack is found. The reasons we need agility today are 
exactly the same as they were three years ago, before the current 
attacks were found; no intuition there.

- We have quantified results that our earlier intuition about 
particular hash functions was wrong. We know for a fact that we 
should not to re-use the same intuition: we know we should look for 
things that don't match what we did before.

Where did you want the intuition to come in here?

--Paul Hoffman, Director
--VPN Consortium

---

From: Hugo Krawczyk <[email-masked]>
Date: Fri, 9 Dec 2005 01:31:00 +0200 (IST)

On Thu, 8 Dec 2005, Stephen Kent wrote:

> term (said the non-cryptographer).At a minimum it might be good to
> what the performance and engineering implications are.Would you
> pre-processing step?

Exactly!  And not only with SHA-256, but with any other existing or future
hash function. I envision randomized hashing as a way to FREE digital
signatures from their dependency on collision resistance (much like HMAC
did for MAC functions)

> That might be an especially attractive approach

As said, I do not see this just as an interim approach, but rather
as a durable SAFETY NET for one of our most precious cryptographic
tools: digital signatures.

Now, while this approach does not require to change hash functions or to
build dedicated hash functions, it does require a change of data encoding
in digital signatures. This is not a trivial change but one we can afford
(and well worth the insurance it buys us). Moreover, if we are going to
clean up our protocols for better robustness to future attacks then we
may well (personally, I'd say WE MUST) take the opporunity to upgrade the
security of digital signatures (especially in applications with
third-party verifiability such as certificates).

This approach is explained in the now-expired draft
draft-irtf-cfrg-rhash-00.txt
which I re-posted now as
http://www.ee.technion.ac.il/~hugo/draft-irtf-cfrg-rhash-00.txt

Since its publication we have obtained very encouraging theoretical
results backing the specific design outlined in the above draft.
An  academic paper with these results will be posted (I'll try to do it
tomorrow) in
http://www.ee.technion.ac.il/~hugo/rhash.pdf

Comments are welcome.

Hugo

---

From: Jyothi <[email-masked]>
Date: Tue, 13 Dec 2005 14:59:46 +0530

Hi,

In IKEv1,  if the peer receives the empty CERTREQ payload data,  it can 
respond with its self certificate issued by any CA.

Is the same concept valid in IKEv2 also??

Thanks
Jyothi