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
