Re: Let's assume DNS is involved

["James Seng" <jseng@pobox.org.sg>]

Mats Dufberg writes:
> That requires more code into SSH since it has to be able to speak LDAP
> too. DNSsec will be needed in any case so that you know that your are
> talking to the correct LDAP server.

You have to add codes anyway, not to mention this is normally out-of-scope.

The bottomline is DNSSEC is more efficient (protocol, traffic, code
complexity etc) but is it worth it?

> >   * Users often assume that DNS names are what they sound like.  Is
> > bankofamerica.com owned by the Bank of America?  Probably, but Verisign
> > doesn't promise anything of the sort.  Encouraging users to put more
> > trust in DNS names could lead to greater potential for abuse.
>
> That problem is not limited to any application keys in DNSsec. You have
> the same problem with SSL certificates signed by Verisign.

Here, we touch onto something else that is really interesting - profiling.

With cert, applications defines a profile for their needs. In internet, we
probably use the PKIX profile. Using DNSSEC and raw keys, we _presumed_ that
this profile only have the domain name and only domain name.

Certificate are more flexible here. But this is a cost-benefit analysis
between keys and cert, not DNSSEC & LDAP. Lets keep it separate.

> Adding application keys into DNS will only increase the load of the
> servers with the zone with the key, and they are the ones that want them
> to be there. Data from the root zone and TLD zone will allready be cached
> from the query of the A record.

I wish it is so simple. There are caches, zone transfer, dynamic updates etc
etc.

Cache is a dual blade here - On one hand, it distributed the load and
contain it near the users. On the other, load of the cache would increase if
TCP fallback (assuming key RR dont fit into DNS/EDNS0 UDP packets) is used
often. ISPs is not going to like it.

-James Seng