Re: Summary of key derivation thread

[Ran Canetti <canetti@watson.ibm.com>]

Radia,

Thanks for summing things up.
I agree that we shouldn't change  the current key derivation
mechanism. But my argument is not that "this is how it is so let's not
bother changing". Rather, the argument is that "from an analytic point of view,
this method is superior to other methods." See mre details below.

> Anyway, hopefully people will find this summary useful, so that people
> can express opinions. I suspect Charlie will vote for not changing
> things, since he has an awful lot of editing to do in not much time
> (including legacy authentication, and the NAT traversal
> stuff is wonderously quirky and complicated). But I think the
> possibilities are:
> 
> a) leave it as it is
> b) replace HMAC with SHA-1, thereby increasing performance, but not
>    changing the security properties

I strongly disagree with this statement. Let me try to explain. 
(In fact, I remember writing similar things on this list in 96, when 
IKEv1 was dsigned...)

It is true that today we don't know of any attack on the protocol 
that would be made possible by replacing the PRF in the key derivation with
simple SHA1. However, by making this transition you "in one blow" lose much
of the analytical and mathematical basis for the security of IKE.
We will no longer be able to claim that "the design of IKE is provably
secure under reasonable and standard assumptions on the hash function in use".
I don't think we can allow ourselves to lose this analytical basis in a 
standard that is indended for wide use.


> c) design something that has enhanced security, but does not attempt
>    to simultaneously enhance performance (might even be slower)
> d) design something that meets both the enhanced performance, and
>    enhanced security goals.
> 
> Radia
> 
> 


Regarding:

>  ease of understanding: (this is my opinion, and was not expressed
>     in the thread, but I guess I'll throw it in). I found it very
>     confusing having the stuff specified as a prf, with exactly two
>     inputs, one "secret" and one not, so that one had to figure
>     out for each input whether it ought to be considered secret or
>     not, and concatenating all the secret values together to form
>     one input, and all the nonsecret ones together to form the
>     other input. It would have taken fewer reads of the spec, and
>     fewer ibuprofen tablets for me, if it had merely been expressed as
>     a hash of n inputs.

I agree that it would be great to able to treat all inputs to the "key
derivation function" on equal terms, and not worry about which is secret and
which is not. Unfortunately, the only way we have today to derive keys in a
way that is analytically sound (ie, in a way that can be proven to be
secure based on reasonable assumptions on the underlying hash functions) 
is by having this split into two types of input:
-A secret input, that is assumed to be random. (we call this input the "key".)
-An input that is not necessarily secret and not necessarily random.

It's a great research problem to find a way to do what you want while
maintaining provability. But until we have that, I suggest that the current 
method will end up minimizing your consumption of ibuprofen.


Ran



BTW, regrading going over 160 "bits of security". I agree that this is a
non-issue from a practical point of view. But for the paranoids who insist 
on doing it, the best way would be to use a PRF with more security, such as
HMAC-SHA2, or any block cipher with long enough keys and block-size.

> 
>