Interesting topic, but I see nothing in this branch of the discussion that necessitates changes to the I-D. Do correct me if I'm wrong. :)
On 9/16/10 11:21 PM, Martin Rex wrote: > 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. _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
