Subject: Re: [Hipsec] Host ID question

From: Tobias Heer <[email-masked]>
Date: Sun, 18 Apr 2010 18:33:55 +0300

Hi, 

Am 16.04.2010 um 23:02 schrieb Robert Moskowitz:

> On 04/16/2010 09:31 AM, Miika Komu wrote:
>> On 15/04/10 23:55, Robert Moskowitz wrote:
>> 
>> Hi,
>> 
>> maybe understood the intent of the question incorrectly, but here goes nothing..
>> 
>>> Why did we specify RSA/SHA1 for a Host ID value in 5201?
>> 
>> RSA does not have any patents and it was interoperated successfully.
>> 
>>> Why the inclusion of SHA1?
>> 
>> Well supported everywhere and it was interoperated successfully.
> 
> I have looked at the offending RFC: 3110 and see that there are TWO RR defined there.  One for RSA keys one for RSA/SHA1 sig RR.  And our format is the former, not the latter, so IMNSHO we made an error to call this RSA/SHA1 and it should have just been RSA.  Afterall, there is nothing hash related in HIPv1 Host-IDs.
> 
If I am not completely mistaken the inclusion of SHA in RSA/SHA1 is to align it to DSA. DSA specifically specifies SHA-1 as hash function to compress the input before applying the costly PK signature scheme. RSA does not have such dependency to a hash function by default. Anyway, you want to compress your input before feeding it to RSA. Hence the combination of both. 

IMHO it is good to have RSA/SHA1 as bundle here.... but I may be wrong, of course.

Tobias

--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer

---

From: Robert Moskowitz <[email-masked]>
Date: Sun, 18 Apr 2010 17:56:09 -0400

> IMHO it is good to have RSA/SHA1 as bundle here.... but I may be wrong, of course.

This applies to Host_ID, which the TLV mimes just the RSA RR, not the 
RSA/SHA1 RR; at least as I look at the RFCs.

Then IF it really IS RSA/SHA1, we would need a Host_ID for EACH hash 
with RSA, when we will be adding a separate TLV for hash....

---

From: Tobias Heer <[email-masked]>
Date: Mon, 26 Apr 2010 16:07:12 +0200

Am 18.04.2010 um 23:56 schrieb Robert Moskowitz:

> This applies to Host_ID, which the TLV mimes just the RSA RR, not the RSA/SHA1 RR; at least as I look at the RFCs.
> 
> Then IF it really IS RSA/SHA1, we would need a Host_ID for EACH hash with RSA, when we will be adding a separate TLV for hash....
> 
> 
I did not full get your point but I will try to answer nonetheless - so I may be wrong or I might even answer the wrong question.

I think the concept of HIP suites covers the issue quite well. We can define combinations of hash functions and signature schemes that make sense or that enable the use of HIP for a special purpose. These suites ca bundle a set of roughly equivalent hash functions and signature schemes - the actual choice of hash function and signature scheme can be communicated during the BEX or the update (for on-path elements). We do not have parameters for conveying that choice yet but as long as it is granted that a host can pick the right suite, the actual algorithms are negotiable.

BR, 

Tobias

--

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 26 Apr 2010 10:48:01 -0400

> I think the concept of HIP suites covers the issue quite well. We can define combinations of hash functions and signature schemes that make sense or that enable the use of HIP for a special purpose…

Yes.  And HOST_ID is ONLY the Public Key algorithm with appropriate 
parameters and key size.  Nothing about Hash is included.  Thus our 
current HOST_IDs are:

DSA
RSA
ECDSA