Re: [Hipsec] Re: Last Call: draft-ietf-hip-dns (Host Identity Protocol (HIP) Domain Name System (DNS) Extensions) to Experimental RFC

On Tue, 29 May 2007, Pekka Nikander wrote:
> I don't have answers to all of your questions/remarks, but I'd take forward a 
> few:
>
>> 1) what if HIP RRs are not queried first?
>>
>>    In the following we assume that the initiator first queries for HIP
>>    resource records at the responder FQDN.
>> 
>> ==> what if it does not?
>
> Remember that this is an experimental spec.  So, taking it the reverse, why 
> should id specify what to do if someone has a reason to do it in another way?
>
> I don't see any specific reason to make any MUSTs or even SHOULDs here: I 
> don't see here any danger for the Internet nor interoperability.  But maybe I 
> just don't understand the dangers you have in your mind.

I have personally no big problems if the spec were to say that 
"HIP-after-A-or-AAAA" were to be left out of scope of this document.

However, what I'm a bit uncomfortable with is that this assumption is 
apparently made in Section 3, "Usage Scenarios", which seems to be a 
section with no normative content.  As such I believe such a 
statement/assumption (if made) should be made in a more prominent 
place in the spec.

>> 3) a premature optimization of HIT lookup tags
>>
>>    Upon return of a HIP RR, a host MUST always calculate the HI-
>>    derivative HIT to be used in the HIP exchange, as specified in
>>    Section 3 of the HIP base specification [I-D.ietf-hip-base], while
>>    the HIT possibly embedded along SHOULD only be used as an
>>    optimization (e.g. table lookup).
>> 
>> .. and in section 8.2:
>>
>>    [...] This is why a HIP
>>    end-node implementation SHOULD NOT authenticate its HIP peers based
>>    solely on a HIT retrieved from the DNS, but SHOULD rather use HI-
>>    based authentication.
>> 
>> ==> this seems like a premature optimization.
>
> Note that these RRs may need to be indexed also by other boxes but the 
> end-nodes.  For them, using the HIT as an index and doing a simple memory 
> comparison instead of calculating a hash may be a win.  Further note that 
> both the sections you quote above discuss only host/end-note behaviour.

This is makes me even more afraid.  If most end-nodes use mechanism A 
but others are expected to maybe use another mechanism B, I foresee 
problems with both mechanisms especially in middleboxes.  It certainly 
won't improve the reliability of the protocol..

>> If you go forward as it is, I think the spec needs to be more 
>> explicit on 1) what happens when HIT received from the DNS does not 
>> match the hash but the hash is checked;
>
> I agree.  FWIW, either ignore the HIT or drop the record.  I think the latter 
> would be the right option, but I may be wrong.
>
>> 2) what are the threats if HIT is used as-is without
>> hash-checking (as allowed by the spec at the moment) when a) the DNS-HIT
>> points to something used by another HI, and b) the DNS-HIT doesn't exist.
>
> I don't understand what you are saying here.

Maybe I was trying to be too terse or I'm missing an assumption about 
how HIT vs HI is validated in other parts of HIP infrastructure.

Let's say I publish a HIPRR with HIT=hash(Y) and HI=X. Someone else 
has HI=Y, and I choose HIT above so that HIT=hash(Y), i.e., create an 
intentional conflict.

Given that the spec does not mandate that the implementations check 
that HIT will correspond to the HI, what's going to happen in this 
case?

Will a middlebox overwrite the index at hash(Y) with HI=X? If yes, 
what is the result?  Will it be a DoS on the host that used HI=Y?

That was the scenario 2.a) above and 2.b) is when HITs don't conflict 
(a more trivial case)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Hipsec mailing list
Hipsec@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hipsec