Subject: Re: [Hipsec] rfc5201-bis issue 29: Use different RSA mode OAEP/PSS

From: Robert Moskowitz <[email-masked]>
Date: Fri, 13 Jul 2012 11:13:26 -0400

On 06/29/2012 05:02 AM, René Hummen wrote:
> A few comments from my side in line.
>
> On 27.06.2012, at 06:10, Henderson, Thomas R wrote:
>> Regarding this open issue, which I posted about on June 18 [*], I 
>> propose the following changes to the RFC 5201-bis text:
>>
>> 1) Section 3
>>
>> OLD TEXT:
>>
>>   HIP implementations MUST support the Rivest Shamir Adelman (RSA)
>>   [RFC3110] public key algorithm, and SHOULD support the Digital
>>   Signature Algorithm (DSA) [RFC2536] algorithms, and Elliptic Curve
>>   Digital Signature Algorithm (ECDSA) for generating the HI as defined
>>   in Section 5.2.9.  Additional algorithms MAY be supported.
>>
>> NEW TEXT:
>>
>>   HIP implementations MUST support the Rivest Shamir Adelman (RSA)
>>   [RFC3110] public key algorithm and Elliptic Curve
>>   Digital Signature Algorithm (ECDSA) for generating the HI as defined
>>   in Section 5.2.9.  Additional algorithms MAY be supported.
>
> ECC libraries are available for most consumer-targeting platforms 
> nowadays. Examples are the relic-toolkit [1] and OpenSSL. Hence, I 
> don't see requiring both algorithms as a major concern. However:
> 1) What exactly are the practical implications of requiring both RSA 
> and ECDSA?
> 2) Resource-constrained devices may only support ECC crypto. Would it 
> make sense to move away from RSA as REQUIRED (seeing that ECC for 
> PC-grade platforms is widely available) or is this perceived as too 
> drastical of a measure?
>
> [1] http://code.google.com/p/relic-toolkit/
>
>> 2) Section 5.2.8, HIP cipher
>>
>> OLD TEXT:
>>
>>   The following Cipher IDs are defined:
>>
>>        Suite ID           Value
>>
>>        RESERVED           0
>>        NULL-ENCRYPT       1     ([RFC2410])
>>        AES-128-CBC        2     ([RFC3602])
>>        3DES-CBC           3     ([RFC2451])
>>        AES-256-CBC        4     ([RFC3602])
>>
>> NEW TEXT:
>>
>>   The following Cipher IDs are defined:
>>
>>        Suite ID           Value
>>
>>        RESERVED           0
>>        NULL-ENCRYPT       1     ([RFC2410])
>>        AES-128-CBC        2     ([RFC3602])
>>        DEPRECATED         3
>>        AES-256-CBC        4     ([RFC3602])
>
> I agree.
>
>> 3) Section 5.2.9, Host Id:
>>
>> OLD TEXT:
>>
>>   The following HI Algorithms have been defined:
>>
>>        Algorithm
>>        profiles         Values
>>
>>        RESERVED         0
>>        DSA              3 [RFC2536] (RECOMMENDED)
>>        RSA              5 [RFC3110] (REQUIRED)
>>        ECDSA            7 [RFC4754] (RECOMMENDED)
>>        ECDSA_LOW        9 [SECG]    (RECOMMENDED)
>>
>> NEW TEXT:
>>
>>   The following HI Algorithms have been defined:
>>
>>        Algorithm
>>        profiles         Values
>>
>>        RESERVED         0
>>        DSA              3 [FIPS 186-3] (OPTIONAL)
>>        RSA              5 [RFC3447]    (REQUIRED)
>>        ECDSA            7 [RFC4754]    (REQUIRED)
>>        ECDSA_LOW        9 [SECG]       (RECOMMENDED)
>>
>>  For DSA, RSA, and ECDSA key types, profiles containing at least 112
>>  bits of security strength (as defined by [NIST SP 800-131A]) should
>>  be used.  For RSA signature padding, the PSS method of padding
>>  [RFC3447] MUST be used.
>>
>> ------------
>>
>> Note, I decided not to bother with adding OEAP or ECIES to the cipher 
>> list, since we already have symmetric keys available and the 
>> ENCRYPTED parameter is lightly used.  If someone would like to 
>> support it in addition to AES-CBC, please propose a specific text 
>> proposal.
>
> The only use case for OEAP that I can see is if the I1 or R1 should 
> contain confidential information for some reason.

Crypto in I1 is a clear resource attack.  That is in large measure why 
there IS an I1 packet.  I have had to deal with proposals to put signed 
objects into 802.11 BEACONs and PROBEs.  But thinking.

R1 confidental information is an interesting thought.  It would take a 
bit to expand on it, but as you note in the end, if someone were to 
propose this, then they can specify this cipher itself.

> Further ahead in the handshake, I also don't see the need to use PK 
> crypto for the ENCRYPTED parameter as symmetric keys are already 
> available at this point. However, if an extension of HIP should need 
> confidential information in I1 or R1, it can specify this CIPHER_ID 
> itself.

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 13 Jul 2012 11:25:50 -0400

On 06/27/2012 01:10 AM, Henderson, Thomas R wrote:
> Regarding this open issue, which I posted about on June 18 [*], I propose the following changes to the RFC 5201-bis text:
>
> 1) Section 3
>
> OLD TEXT:
>

This is a REALLY important shift for a crypto system. I feel we should 
take it. Even with the ever increasing power in processors today, there 
are many reasons of perfer ECDSA keys over RSA. And even with DEX, there 
are 'mid size' systems plus constained communication links where ECDSA 
will seriously outperform RSA.

>          AES-256-CBC        4     ([RFC3602])

DES is dead. Long live the new king. I have spoken to a number of 
serious cryptographers, and I am not overly concerned in only having one 
block cipher here.

> Note, I decided not to bother with adding OEAP or ECIES to the cipher list, since we already have symmetric keys available and the ENCRYPTED parameter is lightly used.  If someone would like to support it in addition to AES-CBC, please propose a specific text proposal.

I agree with this. There is ONE case and that is to have the ENCRYPT 
content to have security context outside of the HIP flow. Say to an 
authentication server. But as indicated, we can let the authors of the 
ID that proposes such a use case to add the cipher.

Oh, I do see use cases where the ENCRYPTED parameter gets more use, but 
it will be in NOTIFYs. Think of HIP as a secure messaging channel itself 
without needing the overhead of a full transport protocol. Sort of like 
secure UDP on the cheap.

Tom, thank you for your effort on this.