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

[Pekka Nikander <pekka.nikander at nomadiclab.com>]

> > > 1) what if HIP RRs are not queried first?
>
> 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.

A suitable restriction of the scope, at an appropriate place, would  
be fine with me.

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

So, maybe add a paragraph about the usability of the HIT for middle  
boxes.

IIRC, the context of discussion was HIP-aware firewalls.  Such  
firewalls could simply snoop HIT RRs as they pass by (or even query  
them if there is a suitable reverse DNS hierarchy, which the draft  
does NOT specify, IIRC).  Then, when they see HIP I2/R2 packets  
passing by, they could use the cached keys, as indexed by the HITs,  
to verify the signatures in the messages.

For such use, I don't see any need of verifying the cryptographic  
relationship between the HIT and HI.  If the signatures in the I2/R2  
don't match, then the firewall doesn't open the connection, and it is  
the user's problem.  No security dangers, AFAICS.  Indeed, it would  
be beneficial if the firewall did NOT try to establish any crypto  
relationship between the HIT and HI, since that would allow the  
relationship to evolve without mandating firewall code updates.

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

You will fail to gain the channel binding property of HIP.  In other  
words, you shoot to your own foot.

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

Well, nothing if the middlebox is implemented correctly.  HIT  
collisions are possible, anyway.  Hence, in such a case the middlebox  
should cache both HI=X and HI=Y, indexed by the HIT.  The fact that  
HIT!=hash(X) shouldn't matter.

--Pekka



_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf