Subject: [dane] The Win-Win-Win proposition

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 7 Jul 2011 11:48:03 -0400

As stated in my previous post, I think that if we combine various approaches
and suggestions we can arrive at a proposition where everyone gets the
functionality they require and everyone gets a protocol gain that they are
looking for.

Before responding 'I don't want to do it that way', please ask yourself if
you can live with the approach proposed. We are dealing with an
infrastructure that is now two decades old and there are many legacy
constraints that prevent a clean approach working for important sections of
the community.

First, we separate the problem into two halves: Key Distribution, Issuer
Accreditation and Security Policy.

*Key Distribution*

Admin generates a self signed certificate with a long expiry date.
Web server generates an OCSP token with the DNSSEC cert chain pickled in as
proposed
Web server returns OCSP token as a stapled response when appropriate client
extension request is received

* Applications can choose to acquire the DNSSEC chain from the OCSP token or
direct from the DNS.
* OCSP tokens limited in validity to the expiry of the pickled DNSSEC chain.
Thus it is invalid for a token containing an RRSIG expiring in a week to
claim to be valid for a year.

Pros:

* Is compatible with legacy browser use of self signed certificates.
* Works when the browser does not have access to a source of DNSSEC data
(e.g. resolver does not forward RRSIG records).
* Changes to client and server require support for OCSP stapling, a feature
that is highly desirable for use in EV cert handling.
* No scripting support is required at the Web server or DNS administration,
the only operation requiring a change to the DNS information is a change of
key.
* Rolling the crypto algorithm can be performed using the TLS negotiation
alone. It is not necessary to wait on the cross product of DNSSEC and TLS
algorithm rollover.
* Fast, the data is returned in the TLS negotiation which is performed
inside an established TCP/IP stream.
* Obviates problems caused by data lengths exceeding the UDP/DNS packet
length.
* Approach is fully compatible with the original concept for OCSP developed
by Mike Moore, Warwick Ford and myself. In SAML terms, the DNSSEC chain is a
form of 'Advice'. The advice slot in SAML was designed to support proofs.
* Extensible to an archive format to provide proof that a particular network
action was justified at the time it was taken.
* Allows browser performance constraints for the key distribution case to be
addressed with full support for wildcards and aliases without the need for
special casing HTTP.

Cons:

* Slightly more complex than pickling the DNSSEC chain into the cert
* Cannot address security policy a-priori as the whole mechanism is
optional.

To Do:

* Write down mechanisms for handling CNAME, DNAME, Wildcards. This is
actually quite straightforward if the signer knows the full scope for which
Web service is being claimed. A server can even synthesize an OCSP token on
the fly if required.
* Write down a mechanism to enable use in a hierarchical structure.

*Issuer Accreditation*

Domain holder publishes CAA record with policy and/or path properties.
Certificate Issuers verify consistency of requests during issue.
Record MAY be published at the domain delegation point (example.com) or the
specific domain name

Pros:

* Is defined, appears to work fine

*Security Policy*

Security policy MAY be specified at the domain name level, be specific to a
particular service at that domain or a particular port on a particular host
offering that service

Examples: This site always offers TLS, this site requires TLS
Examples: This Web server always offers TLS

In the Web case we really have two separate security policy interests
associated with TLS

* Promiscuous security: This site always offers TLS, please use it.
* Strict security: This site never accepts insecure connections except to
give a redirect to a secure one.

google.com is an example of a site that might use the first approach.
paypal.com is an example of a site where the second would be more
appropriate.

Rationale:

We know that we require greater granularity than domain names
Specifying greater granularity requires use of prefixes
Use of prefix records only works in the expected manner if the prefix is
applied to a canonical name.

DNS Solution:

Resolution of security policy is multi phase.
First phase looks for a DNS record that never takes a prefix (e.g. CAA) this
approach is thus compatible with wildcards and aliases, including possible
new alias forms that may be created.
If a record is found it will either be at a canonical name or the result of
a wildcard match. In either case there is a canonical name at which to
continue resolution if necessary
If the result of the first phase indicates that greater granularity is
required, the appropriate prefix is applied to the canonical name resulting
from the last lookup.

This solution would be an additional method of distributing the information
proposed for distribution in HTTP headers. The difference being that this
approach permits action to apply on every connection, not just secure after
first connection.

Pros:

* Provides a comprehensive framework for addressing all aspects of security
policy
* Allows extended discovery to be addressed in the same framework
* Full support for Wildcards, CNAME, DNAME
* Extensible to support negotiation of Web Service protocols and Internet
protocols. Can greatly simplify protocol management.

Cons:

* Obtaining security policy information will require extra DNS lookups and
DNS processing on every single transaction to a domain for which there is no
existing cached data whether HTTPS is indicated or not.
* Depends on the client having access to DNSSEC data.

*Deployment*

I see three potential deployment communities, Web Browsers, Web Services and
CAs.

*CAs*

CAs will deploy CAA because it is their best protection against being
extorted. I did not want to raise that particular interest before the
attackers did, but that was one of my concerns.

CAs have a big stake in making OCSP stapling happening. This proposal will
be highly sympathetic to that goal.

*Web Browsers*

Deployment in Web Browsers is more difficult than many suppose. While there
are comparatively few browsers and deployment by three or four major players
can get deployment to happen quickly, getting any change agreed can take a
very, very long time.

Getting anything to happen in the browser world first requires the gate
keeper at at least one browser provider to accept the proposal.
Unfortunately this is a necessary, not a sufficient step. While most of the
gatekeepers have the ability to veto a proposal very few if any have the
power to say yes. Modern browsers are written by teams of hundreds of
people. In many cases the teams cross organizational boundaries (e.g.
calling WebKit, OpenSSL).

Thinking of the problem from a gatekeeper's perspective, I could see myself
writing some code and getting the organization to accept it. Getting the
organization to accept a dependency on a new external code development
project is a much, much tougher sell. DNS libraries are big and they are
complex.

The code that I have been looking at in the past few weeks does not remotely
match the type of security requirements I place on code. Strings are
allocated from static memory, unsafe buffer handling abounds, use of
sprintf, etc. etc. Auditing one of the proposed libraries to ensure
compliance with code quality requirements would be a huge undertaking.

The Key Distribution proposal described is presented in a form that allows
for immediate use to address the Key Distribution issue. It is maximally
compatible with the existing code paths. If a self signed cert is presented,
the browser simply calls up validation for the stapled OCSP response.

Mainstream Web browsers may adopt the Security Policy proposal over time as
it is applied in other areas. But it can't be relied on as an early adopter.

I would however hope that we could persuade groups like Tor that serve
communities under particular threat of a sophisticated downgrade attack to
be early adopters of this approach.

*Web Services*

Deployment for some Web Services and for some Web Service platforms is much
easier than for browsers.

* New Web Service protocols are developed every day.
* Every developer is going to either use an existing platform or write one.
* There is competition among platform developers
* The DNS based security policy approach allows security and administration
to be greatly simplified.
* The Security Policy approach is extensible to support protocol and service
negotiation.

I believe that if the right tools are offered, Web Services could start
using this approach very quickly. It solves problems that are currently not
addressed at all or only addressed through proprietary approaches.

*Roadmap*.

The Internet is large, there are a billion users. Deployment of any
technology takes time. It is important to be realistic in setting
expectations.

The approach proposed allows immediate progress on the Key Distribution and
Issuer Accreditation fronts. Progress on the Security Policy side will take
a little longer as we will probably need to have a spec for the first two
settled before we start work on the second.

-- 
Website: http://hallambaker.com/