Re: [IPsec] Puzzle algorithm negotiation

[Yoav Nir <[e-mail]>]

> On Jan 25, 2015, at 8:58 PM, Yaron Sheffer <[e-mail]> wrote:
> 
> Hi Yoav, Valery,
> 
> I agree with Valery's proposed redefinition of the proof-work-work, based on the PRF.
> 
> I am currently off-line so my question may have been answered in the pull request, but: can we make it very clear that the PRF used for the POW must be the very same as the one selected by the responder for the IKE SA?

It is possible, but I don’t see why it’s a good thing. Suppose the conversation goes like this:

Initiator: I want (AES-CBC-128 or AES-CBC-256) with (AUTH_HMAC-SHA1 or AUTH_HMAC-SHA256) and (PRF_ HMAC-SHA1 or PRF_HMAC-SHA256) and (Group 2 or Group 14)

Responder: First do proof-of-work with PRF_HMAC-SHA256

Initiator: Here’s the proof-of-work, now I want (AES-CBC-128 or AES-CBC-256) with (AUTH_HMAC-SHA1 or AUTH_HMAC-SHA256) and (PRF_ HMAC-SHA1 or PRF_HMAC-SHA256) and (Group 2 or Group 14).

Responder: Fine, I choose AES-CBC-128 with HMAC-SHA1 and PRF_HMAC-SHA1 and Group 2.

What is the benefit of forcing the responder to choose the same PRF algorithm twice? What is wrong with having it choose PRF_HMAC-SHA1?  Sure, we *can* do this, but why?

> People may not like it (I don't) but a major reason for including agility today is FIPS silliness. One day people will be forced to rip out any mention of SHA-256 from their code, and we don't want to need to reopen the RFC.

Some algorithms are also more fashionable than others.

Yoav

> 
> Thanks,
> 	Yaron
> 
> On 01/19/2015 12:02 AM, Valery Smyslov wrote:
>> Hi Yoav,
>> 
>>    Pull Request: https://github.com/ietf-ipsecme/drafts/pull/2
>> 
>>    Hi,
>> 
>>    Valery has created this pull request. During the meeting in Honolulu
>>    and subsequent discussion on the list, several people requested that
>>    there be a negotiation of the algorithm used in the puzzle rather
>>    than fixing it to SHA-256.
>> 
>>    The pull request suggests figuring out which algorithms the
>>    Initiator supports by examining the SA payload in the IKE_SA_INIT
>>    request, and using the PRF algorithms.
>> 
>>    I’m posting this to the list, even thought we’re not sure about
>>    this. Specifically, PRF_AES128_XCBC and (I think) PRF_AES128_CMAC
>>    won’t work with the bitcoin-like puzzle that is currently in the draft.
>> 
>>    Why?
>> 
>>    For convenience assume a 16-byte cookie, a fixed zero IV (as always
>>    in AES-XCBC) and fixed zero key.
>> 
>>    So let Y = AESENC(key, IV XOR COOKIE) = AESENC(zero, COOKIE)
>>    Let Z = AESDEC(key, zero) = AESDEC(zero, zero)
>>    Extend the cookie by Y XOR Z.
>>    The result will give you a 128-bit tag of all zeros. Way too easy.
>> 
>> You forgot about the mandatory 10* padding in AES-XCBC.
>> So, the result of AESDEC(zero, zero) should not be a random
>> string, but should look like properly padded one.
>> But anyway, I think that if we use PRF for puzzles, then the puzzle
>> definition should be changed.
>> Let R=PRF(K,S). Then the puzzle should be: using supplied cookie as
>> message S,
>> find a key K so, that result R contains the requested number of trailing
>> zero bits.
>> I'm not a cryptographer, but I think this variant of puzzle should be secure
>> for all PRFs, defined in IPsec. Why? First, every secure PRF is a secure
>> MAC
>> (not visa versa). This is pointed out by several sources. Then, secure MAC
>> should not allow attacker to recover a key given the message and
>> the authentication tag. In our case the authentication tag is not fully
>> given,
>> but it must have some properties (desired number of trailing zero bits),
>> so it is not arbitrary.
>> 
>>    Another way to do this is to add a notification in the Initiator’s
>>    request listing the hash algorithms that it supports. We could reuse
>>    the RFC 7427 registry of hash algorithms.
>> 
>> I don't think this is a good idea. First, it will require initiator to
>> include
>> a list of supported hash algorithms into request message. This will
>> unnecessary increase its size in all cases: at this point initiator
>> has no idea whether responder will ever use puzzles or even
>> whether it supports them. I think this is a waste of resources,
>> especially taking into consideration that we may reuse
>> information, that is always present in the request message.
>> 
>>    Personally, I really don’t like this algorithm agility, because we
>>    don’t want to give the Initiator the options of a hard vs easy
>>    puzzle. So suppose the Responder supports two algorithms, SHA-256
>>    and SHA-512, and that the latter is half as fast as the former, then
>>    a SHA-512 puzzle would have to have 1 bit less than the SHA-256
>>    puzzle. But in fact, we know that SHA-512 is faster on 64-bit
>>    platforms, while SHA-256 is faster on 32-bit platforms. Add some
>>    GOST-certified hash to the mix, and the administrator’s task becomes
>>    that much harder.
>> 
>> If the difference in algorithms speeds is significant, then some weights
>> could be
>> added to algorithm definitions to make the required time to solve puzzle
>> roughly the same
>> on the same platform.
>> 
>>    OTOH often when a protocol is published without algorithm agility,
>>    we end up extending it later.
>> 
>> Exactly.
>> 
>>    Yoav
>> 
>> Regards,
>> Valery.
>> 
>> 
>> _______________________________________________
>> IPsec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ipsec
>>