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

Hi Pekka,

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.

> 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.

> 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.

--Pekka (the other one)

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