[Hipsec] Re: some comments on draft-ietf-hip-dns-09

Hi Gabriel,

On Tuesday 10 July 2007 09:59, gabriel montenegro 
wrote:
> I realize these comments are soooo late they might
> instead be considered early for the next revision of
> the document. Your call.

Later is better than never :) Thanks for the comments!

> I'm not a DNS expert so have no comments on those
> aspects of the draft. I do have some concerns.
>
> First technical comment:
> Section 5.1 only specifies RSA and DSA. Suggest
> including ECC as well and getting on with the
> times...

I never thought about this. This is something that the 
working group may consider. Note however that 
including ECC in the DNS RR would not be sufficient; 
the HIP protocol would also need to be 
extended/modified to be able to handle ECC public keys 
and signatures.

[...]

> But my main concern is with the fact that this RR
> encodes a raw public component. This is dangerous.
> With CGAs, the assumed (as far as I can see) usage
> is that they are meant for ephemeral (short-lived)
> usage. But by publishing HIs in the DNS, we are
> promoting them as long-lived entities. Accordingly,
> the usual knee-jerk reaction to any such usage of
> public key technology is: how do you handle
> revocation? By encoding a raw public component you
> now rely on the DNS to control usage of that HI.
> This is a dubious proposition. If, however, the
> encoding allowed for HIs to be certificates
> (self-signed or CA-issued, whatever) then you could
> have the flexibility of populating certain fields to
> aid in revocation by pointing at OCSPs or aid in CRL
> resolution, without *exclusively* relying on
> DNS-based mechanisms to limit usage of the HI in
> question.

I've never thought too much about revocation in the 
context of HIP...

It is possible to control (i.e. limit in time) usage of 
the HIs by limiting the TTL of the DNS zones in which 
you store HIP information. 

As you note the HIP protocol itself has no provisions 
to handle certificates with OCSPs as HIs. One guess is 
that it might have been a design choice, that the 
identifiers used by HIP are purely flat, 
non-hierarchical, and can't be traced back to any kind 
of authority. I am however certainly not right, others 
on the list might know better...

Also, and FWIW, HIP would not be the first protocol to 
store raw public keys in the protocol, since there's 
already "A Method for Storing IPsec Keying Material in 
DNS" [RFC4025].

I do not have a strong opinion on the matters. I think 
your proposal of allowing HIs to be certificates is 
interesting. 

What does the WG at large think of that?

--julien

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