Re: From whence we came...

[Keith Moore <moore@cs.utk.edu>]

> Keith Moore <moore@cs.utk.edu> writes:
> 
> > It's not clear to me why you need to verify the authenticity or
> > integrity of a blob if you can't interpret the blob anyway.
> 
> Perhaps.  But keep in mind that there are some blobs that don't have
> any internal integrity/origin protection at all (eg. ssh keys or
> freeswan keys).  DNSSec fills that void perfectly.

mumble.  My trust in ssh keys is based on prior experience in using
that key to interact with a particular host - hopefully the key
is initially obtained over a network that is secure or unlikely to 
be compromised, or the key obtained in this manner can be verified 
out-of-band.  Trust in DNSSEC is based on different factors.  

While I wouldn't mind having the ability to verify ssh keys using 
DNSSEC, I wouldn't necessarily want DNSSEC verification axiomiatically
treated as valid by ssh.  

And this is still a different issue from putting ssh keys directly 
in DNS.

> > I'm aware that the discussion started in terms of using DNS.  I don't
> > know how the charter will end up, whether it will presume DNS as part
> > of the solution or not.  IMHO it would be wrong for the charter to
> > presume DNS distribution and DNSSEC as mechanisms even if the charter
> > were limited to associating key material with DNS-based names.
> 
> Honestly, I don't think we want to try solving the whole key
> distribution problem.  I think we should definitely keep ourselves
> limited in scope.  In particular, I think we should limit ourselves to
> distributing keys for identities that can be represented as DNS names
> (definitely host names, maybe user names).

Offhand that sounds like a good scope.  I might also include IP addresses.

> > I agree that there is a large set of applications for which DNS should
> > be part of the mechanism for locating keys.  Any application that
> > wants to associate meaning with DNS names, and probably IP addresses,
> > would be a likely customer for such a mechanism.
> > 
> > Whether DNS is a good mechanism for actually distributing keys is a
> > different question.  Several limitations in the DNS protocol make
> > me dubious about this.
> 
> I'd like to hear your reasoning for this, but perhaps that should be
> taken offline?

Briefly: limited number of RRs, difficulty in supporting new RRs, 
inability of DNS queries to simultaneously support multiple RRs, 
difficulty of supporting arbitrary signature types, size limitations
on RR data, size limitations of DNS PDUs, difficulty in using DNS 
to store information about things other than DNS names (e.g. user 
names, URIs), difficulty in fine-grained delegation - say to individual 
users (you end up needing to define a new zone for each one), difficulty 
in supporting new signature types.

there are probably some others.  recent extensions might solve some
of these problems, but it's not clear that those extensions work 
through existing DNS intermediaries.

> > Whether DNSSEC is a good mechanism to verify the authenticity of keys
> > is yet another question.  As far as I can tell DNSSEC is potentially useful
> > but has narrower applicability than the general key distribution mechanism
> > being considered.
> 
> Agreed.  There are some keys for which DNSSec is absolutely necessary.
> There are other keys for which DNSSec would be nice but isn't
> necessarily required.

agree.

Keith