|
Re: [Hipsec] Re: Last Call: draft-ietf-hip-dns (Host Identity Protocol (HIP) Domain Name System (DNS) Extensions) to Experimental RFC
2007-05-30 01:22:16
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(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
|
|