Re: private algorithms and the DS record

[David Blacka <davidb@verisignlabs.com>]

Edward Lewis wrote:

> Course, here's where the problems begin:
>
> 1) If the private alg name is one not understood, there's no way to 
> validate that the received DNSKEY set for X is genuine.
>
> 2) If the private alg name is understood and the DNSKEY set fails to 
> validate then you have dubious data
>
> 3) If the private alg name is understood and the DNSKEY set passes 
> validation you are in luck.
>
> The problem is with #1 and #2.  You can't decide if the received data is 
> genuine (and you therefore ought to proceed as if you can't validate the 
> data) or if the data is sub'd in for a set that oughta fall into 
> category #3.

Once again, Ed dazzles me with his insight.  I had not yet considered 
the security implications of this issue, only the asymmetry of it.

Just to summarize: Ed has shown that a zone signed only with a known 
private algorithm (and any number of unknown algorithms) could be made 
to appear (erroneously) insecure via a MitM attack.

> It seems to me to be that A) private algorithms are hosed or B) the DS2 
> RRSet includes the sub-algorithm field (the name of the private 
> algorithm).  Well, those are my two first approximations - maybe there's 
> a way to squeeze the private alg name into the hash in the DS for 
> private algorithms before it's too late.

Well, if we don't fix it, then yes, I believe that private algorithms 
are hosed.  As for B), I don't think we need to define a DS2, we need 
merely to define the same rule for DS records as is defined for DNSKEY 
and RRSIG.

For instance, we could modify the second sentence of the first paragraph 
of records-11, Appendix A.1.1 from:

   The public key area in the DNSKEY RR and the signature area in the
   RRSIG RR begin with a wire encoded domain name, which MUST NOT be
   compressed.

to

  The public key area in the DNSKEY RR, the signature area in the RRSIG
  RR, and the hash area in the DS RR begin with a wire encoded domain
  name, which MUST NOT be compressed.

Plus a similar transformation in the next paragraph for the OID case, 
assuming that it isn't too late to modify the document before RFC.

That would give the DS as much attention as anything else with respect 
to private algorithms, in any case.

--
David Blacka    <davidb@verisignlabs.com>
Sr. Engineer    Verisign Applied Research

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>