Thinking aloud here, if we did anything like that, the obvious approach would be to make the name completely opaque and a digest function of the root of trust.
Something like: SHA2-256-JBSWY3DPEHPK3PXP.crypt If you have a service that allows people to choose their names then you are going to require at least as much management as you have in ICANN. Otherwise you will have all the typo squatting issues all over again. You also introduce lots of attack vectors and complexity. The simplest way to make everything work would be to require SHA2-256 (root) = JBSWY3DPEHPK3PXP Services within the zone would need to present a credential that was signed under 'root' at some point in the connection establishment phase. That could be DNSSEC but might make more sense as TLS. Resolving the DNS name could be achieved through any service that can deliver a string of bits that eventually works. It is not necessary to rely on any given party for that process. I can see that approach having the functional benefits of ID based encryption. It has minimal moving parts. When it comes time to change the trust root for whatever reason there would need to be some form of redirect mechanism. To make use of such a scheme with human friendly names it would be necessary to map a .com or .info or whatever DNS name to the .crypt domain. I can't see this catching on to a very large extent in the Web area. But I would see as being very useful in the device encryption area. On Wed, Jan 18, 2012 at 11:04 AM, Adam Back <[email protected]> wrote: > Hi Phill > > I think many will agree with the sentiments about central control of DNS, > it > is a related problem for sure. As well as the new attempt to force ISPs to > block DNS lookups, I think the US and other countries have also been > seizing > domain names, typically without any legal due process even. > > Both actions do seem regressive moves to me. > > Maybe we could also consider an alternate domain like .alt that is first > come first served, with cryptographic protection against non-owner approved > changes, such that it is technically impossible to remove names and > applying > political or legal pressure on the registrar is pointless. > > I made a proposal relating to the DNS resistance to censorship back in 1999 > or so, this is a 2001 write up of that "auditable namespace" proposal using > merkle hash trees. > > http://cypherspace.org/p2p/**auditable-namespace.html<http://cypherspace.org/p2p/auditable-namespace.html> > > > Similar concepts and strategy could be used to validate domain to > certificate bindings. > > Adam > > > On Wed, Jan 18, 2012 at 10:24:58AM -0500, Phillip Hallam-Baker wrote: > >> Since today is the US SOPA/PIPA blackout day, it is worthwhile considering >> the fact that PKI is not the only component in the Internet trust >> infrastructure and that connecting to man in the middle sites is not the >> only risk we face. The name service and denial of service are also >> important factors in the trust infrastructure. >> >> The logic of the SOPA/PIPA protests is that Internet application and >> platform providers empower their users with an effective switching power >> for their name service. Part of what is being suggested here is to empower >> the user by giving them alternative options for selecting their trust >> provider. >> >> >> I have been worried about the various forms of coertion that the DNS >> infrastructure makes possible for some time. And it is not just a question >> of 'can we trust the US'. SOPA/PIPA make clear that any government can >> introduce the same sort of attempted controls. >> >> The only way we can protect ourselves is to empower our customers with >> switching power. Traditionally every business tries to bind themselves >> closer to their customer and make it difficult for them to switch. But a >> business can actually be more successful by adopting the opposite >> strategy. >> Consider the success of Signio over Cybercash. The big difference in the >> product was that Signio was designed to empower the customer by giving >> them >> the power to switch between payment processors and thus get the best >> rates. >> >> A US based company like Google or Comodo cannot claim to be immune to >> interference from the US Congress. But what we can do is to avail >> ourselves >> of the same defense that ICANN has always used - try to pressure us and >> everyone will simply find another provider. What keeps ICANN strong is the >> fact that they are weak. >> >> >> So we have a trust provider problem and a name provider problem. >> >> I do not propose that we combine the two problems, but I do think that if >> we end up proposing a new client/service protocol for resolving trust that >> we make sure that name information can flow through the same pipe. I would >> have preferred DisplayPort over DVI because I would only have needed to >> run >> one 50 foot cable per monitor between my desktop and the machine room. >> >> >> Let us imagine that there is an easy way for an Internet user / sysadmin >> to >> configure a machine to use a specific name and trust provider. The >> configuration would require some vestigial DNS service and quite likely >> some dependence on a pre-configured trust store. But once the machine has >> been configured to direct name and trust queries to dns.com or to >> example.com or bigbank.net or whatever, it can establish credentials that >> are used to secure all future communications. >> >> At an abstract level, this might apear something like this: >> >> Client: I want to connect to the http service of example.com, attempt >> #1, >> nonce is P >> Service: Use TLS 1.1 or better, cert chain contains cert X, IP address Y, >> port Z >> >> or >> >> Service: Just don't go there, its bad >> >> >> The service response might be limited to just the summary or contain >> further levels of detail. The original idea I had for the 'advice' slot in >> the assertion infrastructure that eventually became the A in SAML was to >> include proof chains for the trust relationship that was established. This >> was when the project was developing a next generation PKI in XML. >> >> So imagine that we adopt a sovereign keys or cert transparency like scheme >> involving notary proofs, the service may flow that data through to the end >> client as needed. This provides for a huge efficiency gain as the service >> can track what data the client already has and provide only the additional >> data necessary rather than complete Merkle chains. >> >> For applications where end-to-end security means 'process at the client', >> this is possible. But I don't think that is actually a very good model >> even >> for the paranoid. I have 40 devices in the house with an IP stack. I do >> not >> want to be managing PKI configuration on each one. In the future I expect >> to have at least 1000 IP connected devices in the house. So if I am >> paranoid I would still want to centralize my trust management only to a >> service I run personally rather than just selecting one. >> >> >> Clearly any client/service protocol here would have to be capable of >> tunneling DNS queries and responses. And for efficiency reasons it would >> be >> desirable to allow UDP transport as at least one protocol option and to >> encapsulate requests and responses in some transport security. >> >> The protocol would also have to support a defensive mode to enable it to >> work properly through NAT boxes, broken DNS resolvers and the like. >> >> >> Now consider what would happen were there to be a government mandate to >> block DNS for a site. This might actually be a reasonable thing to do if >> the objective is to protect the end user. Blocking access to phishing >> sites >> is something people will pay money for. Blocking access without due >> process, effective right of appeal or any of the abuses that have occurred >> in recent cases would cause a flight to name services outside the control >> of the government in question. >> >> >> -- >> Website: http://hallambaker.com/ >> > > ______________________________**_________________ >> therightkey mailing list >> [email protected] >> https://www.ietf.org/mailman/**listinfo/therightkey<https://www.ietf.org/mailman/listinfo/therightkey> >> > > -- Website: http://hallambaker.com/
_______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
