Subject: [websec] Reasons why DANE does not meet all Security Policy Needs

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 Nov 2011 15:48:16 -0500

More information on the scheme I am proposing is to be found in the
following document:
http://www.ietf.org/id/draft-hallambaker-securitypolicy-01.txt

One of the conversations that came up yesterday was why WebSec should do
pinning if DANE is already doing this via DNSSEC. At the top level there
are three major reasons.

1) WebSec was originally chartered to consider Security Policy in the form
of Strict security. Thus as a process matter WebSec has a strong claim to
address other forms of security policy

2) The DANE charter does not explicitly call out security policy as a
deliverable. Thus while DANE has made Security Policy its primary concern
as a WG it has no process claim to 'own' the issue as an IETF matter.

3) The approach taken in DANE does not support Security Policy as a stand
alone function., It is only possible to use their key distribution if you
also buy into their key distribution, it is only possible to use their key
distribution if you buy into their security policy. It is not possible to
use either independently. As a result I am unable to use either.

In particular, I am very, very annoyed at the constant bleating of 'don't
beat up on DNSSEC' followed by attacks on the existing PKIX infrastructure
based on the claim that DNSSEC is absolutely perfect in all respects and
'more secure'.

This happened several times during the WG meeting this morning. I note that
each of the three individuals who protested that this was not the place to
discuss the security of DNSSEC then went on to do exactly that. So what
they were really demanding was a chance to get in as many free hits as they
like against PKIX while running to hide behind mummy when the security of
their proposal was examined. I do not have a great deal of respect for that
mode of argument. If people want to argue that their new proposal is better
then fine. But they are not going to get the free hits they demand.

There are in fact many reasons to be skeptical of the DNSSEC system. Note
that I am a proponent of DNSSEC and have argued for advancing it for the
past ten years. But it is still a completely new infrastructure and is
simply not ready for use as a PKIX replacement even if that is considered
to be a worthwhile goal.

My interest in DNSSEC has from the start been to provide a model of key
distribution for very low assurance keys and to provide the basis for a
security policy mechanism for very high assurance keys. The two application
areas are almost entirely disjoint.

First let us consider the components of the DNSSEC system. They have
different levels of maturity.

1) ICANN Root Infrastructure
2) Domain Level Signatures
3) Registration of Domain Level Keys via registrars
4) Interface between the registrars and the registries
5) DNS query protocol

Of these (1) and (2) are as good as can be expected.

The major problems are (3) (4) and (5).

On (3) the major problem is that the registrars are not specialists in
cryptography. Sale of DNS names is a loss leader as far as their business
models are concerned. As a commercial proposition it is highly unlikely
that the registrars are going to invest in enabling DNSSEC unless that is
going to provide a commercial return. Demand for DNSSEC is currently
negligible and likely to remain so until critical mass is established.

As a commercial proposition it really makes no difference to a CA if the
basis for PKI is PKIX or DNSSEC. They both require the same degree of
customer hand holding and support. During a transition period customers
would need to deploy both so DNSSEC represents a growth opportunity. DNSSEC
does not provide accountability and so does not provide a basis for EV type
certificates.

The major security problem is at step (4). Contrary to the claim of having
a single CA, the DNSSEC ecosystem actually has a separate CA for each top
level domain and several hundred entities that function as RAs beneath it.
So even though I can only get a .com through the VeriSign registry, I
cannot buy a domain from VeriSign direct. I have to go through one of
several hundred registrars or several thousand resellers instead.

The degree of complexity in those systems is vast. There is no party in the
system that has oversight of the whole thing. While there are procedures in
place that enforce 'domain locking' at the registry level, these depend on
the interface between the resellers and the registrars being correct.

Domain hijacking at the registrar level is a very, very frequent
occurrence. So frequent that it no longer even attracts notice unless the
target is a major player such as Twitter.

On (5) the deployment of the DNS protocol does not support DNSSEC
sufficiently reliably to use it as the basis for distribution of either key
distribution or security policy.

The most important limitation on the DANE infrastructure is what it does
not attempt to provide. There is no party in the system that accepts any
liability for operation of the PKI under any circumstances whatsoever. As a
result the injured party in a breach is likely to sue every party they can
in a joint action including the registry, registrar and browser vendor. Of
these the registry is likely to have a good legal excuse, the registrar is
unlikely to have the resources to fight the suit let alone pay damages
leaving only the deep pockets of the browser vendor to catch the liability.

Expecting that the browser vendors would accept this situation is rather
naive. The reason that Microsoft and Netscape insisted on the formation of
VeriSign (the CA) in the first place was to catch the liability.

DANE as currently proposed requires that the domain owner switch from the
established PKIX infrastructure that has known vulnerabilities and a very
low rate of breaches to a completely new and untested infrastructure that
has frequent breaches and is potentially subject to new and unexpected
failure modes. DANE is intentionally an all or nothing proposition. I have
to eiher drink all the KoolAid or not do any of it. I cannot pick out and
use the parts that I want independently.

Unpacking the key distribution and security policy functions and addressing
them separately allows for the limitations of the immature DNSSEC system to
be worked around.

For key distribution any system must be as reliable as existing use of self
signed certs. So I want to use a system that only depends on components (1)
and (2), the components that are currently mature. DANE does not meet my
needs in that respect because it forces me to depend on the DNS query
protocol infrastructure what has a major legacy transition problem.

The problem of key distribution has in my view been almost completely
solved by Kaminsky and Langley in their proposal to pickle out the DNSSEC
chain and place it within a certificate. If they are willing to change that
approach to putting the DNSSEC validation chain into a stapled OCSP token
instead then the objections resulting from the different validity intervals
of the DNSSEC data and the Certificate data are completely resolved. The
self signed cert can then have the long term validity interval required to
make use acceptable with legacy browsers that will query the user on every
certificate change and the DNSSEC validity information can be regenerated
each time the zone is re-signed.

For Security Policy it is very clear that DNS is one of the mechanisms that
should be involved. DNS is the Internet infrastructure for making
authoritative assertions about domain names. Security policy is an
assertion about a domain name.

Contrary to the arguments raised in the WG meeting however, effective use
of Security Policy published in DNS does not mandate DNSSEC.

The most valuable use of Security Policy information is to detect and
report violations. Blocking user access to a site only protects one user
and false positives impose a major cost. Since Security Policy is a new
concept, false positives are inevitable. Over the past decade there has
only been one incident in which genuine positives would have been detected
and then only if you happened to be in Iran. While demanding a 'hard fail'
position is clearly desirable to me from a security point of view, I can't
see that I am likely to get it while the browser vendors still refuse to
hard fail on lack of access to OCSP data.

Over time we may well move to a position where browser vendors are willing
to move to a hard fail model on security policy misconfiguration. In the
transition period, I see the following as being more likely to be
acceptable:

* Security Policy Origination

Security policy may be declared through DNS records, HTTP headers or out of
band means (e.g. tell CABForum or APWG that you are a really serious
phishing target).

In some cases security policy will be obtained heuristically.

* Security Policy Curation

Security Policy is hard because it throws up many corner cases that can
easily rat hole. Having some form of curation of the raw policy data allows
these corner cases to be pushed to some intermediary that can handle them
intelligently on a case by case basis.

The principle experience that IETF has of security policy is in DKIM.
Actual deployed DKIM security policies are of variable quality. But even
though the information they provide is not a 100% accurate guide, DKIM
works well in practice as one of the (many) inputs into anti-spam systems.

Depending on raw Security Policy information may well prove to be
impractical. But that is not the only option we have. Anti-Virus systems do
not depend on code signing alone, they use it as one input into their
systems. Code signing does not prevent code from being malicious, but once
malicious code is found signed under a particular key then all other
software signed under that key comes under a higher degree of scrutiny.

If a Security Policy system is deployed and it just works then this
component will be superfluous. Otherwise the ability to perform some form
of curation of the raw security policy provides the answer to the various
objections being made of practical experience such as what to do when the
system administrator fouls up.

At present the response to a CA breach involves various parties round the
world being called out of bed to respond. We are dealing with an
intelligent attacker who changes their attack in response to the
countermeasures deployed against them. Thus having the option of curating
the raw policy data is likely to be of significant value in developing the
right response.

* Security Policy Distribution

Security policy may be distributed through multiple modes of distribution.
No single distribution mode can ever be relied upon in all circumstances
and provide the scalability and robustness required.

If there is knowledge of an active attack against a very high value domain
then the most appropriate technology is to push out a hotlist of security
policy statements that includes that domain. That particular mechanism does
not scale but it is capable of scaling to provide absolute protection for
95% of the most risky transactions. Even if such a mechanism is never
actually used it would be very useful to have in our back pocket to use
when needed.

http://www.ietf.org/id/draft-hallambaker-securitypolicy-01.txt

Hotlists do not scale and so some form of online mechanism is essential.
HTTP headers and DNS statements both have pros and cons. But in practice
both these channels are subject to MITM attack and DoS by nation state
actors. Note that for the Iranian State adversary, denying access to
Twitter is one of their main goals.

In practice any distribution mechanism that is going to be effective in
those environments is going to have to be capable of circumventing the
normal communication channels that can be blocked. Thus end clients are
going to need to be equipped with the capability to employ a range of
distribution mechanisms.

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