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 _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
