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)
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf