Re: [certid] DNSSEC-based name canonicalization

[Martin Rex <[e-mail]>]

Matt McCutchen wrote:
> 
> On Fri, 2010-09-17 at 00:34 +0200, Martin Rex wrote: 
> > Cleanup of my prior message:
> > 
> >  
> > Matt McCutchen wrote:
> > > 
> > > On Thu, 2010-09-16 at 07:27 +0200, Martin Rex wrote:
> > > > Clearly unsafe operations:
> > > > 
> > > >   - building a reference identifier from the result of a
> > > >     DNS CNAME lookup
> > > > 
> > > > (the use of DNSSEC does not make this safe)
> > > 
> > > Why not?  I'm not saying it's good practice, but I don't see an actual
> > > vulnerability.
> > 
> > You need two characteristics:
> >  
> >   (1) _trustworty_ information source for a name transformation
> >   (2) _protected_access_ to the information source
> > 
> > DNSSEC meets (2) but not (1)
> 
> Why not (1)?  It should go without saying that by DNSSEC I meant "DNSSEC
> with a set of trustworthy trust anchors that will get us to the desired
> signed zone".  From there, the DNS admin has full authority to say what
> certificates a client trying to connect to a host in her zone should
> accept.

DNS needs to be available, fast, efficient and low-low-low cost.

The cost of creating and maintaining DNS records with any trustworthyness
that is measurably distinct from zero, with the necessary expertise to
set up and devotion to practise scrutiny for every change to the data
is probably going to far exceed the funding of most, if not all DNS admins.

Are there already workable procedures and APIs for software to
distinguish "normal" DNSSEC lookup results from "trustworthy" DNSSEC
lookup results with some level of portability?  How and how often
would admins/consumers have to update and reconfirm every "trustworthy"
DNSSEC key they keep?

> 
> We could have a record, CERTNAME or something, that specifies the
> hostname for which the certificate should be valid (via keyassure or
> PKIX + server-id-check).  I realize now that it would be dangerous to
> reinterpret CNAME for this purpose, just as it is dangerous to
> reinterpret CERT as making an assurance, but that is a separate issue.
> I still wouldn't advise doing it unless we come up with a compelling use
> case.

DNS domains is a resource that is managed pretty arbitrary on a
first-come first-served basis.  It has some loose "a domain is leased
to at most one entity at any single time" provision, that's it.
DNS is vital for the internet, so it needs to remain fast,
efficient and free, and all of that combined makes it hardly
usable to bootstrap an infrastructure of trust, with any meaningful
level of trust.

The fraction of resources that web browsers accesses through HTTPS,
where the first HTTPS link is served through a page received via
HTTP in a completely untrusted fashion is mindboggling.
Example "ebay".  What do you think: how many users that login
through the ebay sign-in page via HTTPS every day, have supplied
the URL of the signin page in a trusted&secure fashion, and
how many open http://www.ebay.<country> and click a link
on that page?

How about online banking?  An internet commerce that cares strongly
about security should serve only one single "301 Moved Permanently"
page with an HTTPS url on port 80, making it difficult to bookmark
anything else than a HTTPS urls to this site.

"Secure" electronic commerce on the internet is often
like a handful of iron rings that are quickly attached to
each other with tiny rubber bands from the kitchen drawer
in order to give the impression of a chain.  Occasionally,
some of these "chains" rip apart by their own weight alone.


-Martin