Subject: [therightkey] Combining name service and trust service

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Jan 2012 10:24:58 -0500

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/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Jan 2012 11:33:41 -0500

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-masked]> 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:
>
>  ______________________________**_________________
>> therightkey mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/therightkey<https://www.ietf.org/mailman/listinfo/therightkey>
>>
>
>