Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

[Phillip Hallam-Baker <[e-mail]>]

David,

When I originally looked at this scheme I thought that it was intended to
reduce the attack surface in the manner you describe.

Clearly if you have two controls, A and B and BOTH must be compromised, the
system is less likely to be compromised than either A or B.

But the design approach taken in the Hoffman et. al. proposal is that
publication of a DNSSEC assurance for a cert disables verification on the
PKIX chain unless the 'preferences' flag is set. This flag will be buried in
a base64 encoded sub-field encoding.

In practice only a proportion of clients will deploy this mechanism. So if A
is PKIX and B is DNSSEC, it will be possible for an attacker to succeed if
either A or B is compromised in one configuration and if either A or A and B
is compromised in the other.


People seem to be confusing the security of the cryptographic protocols with
the security of the infrastructures that support them. The weakest link in
any competently designed security scheme is people and processes. The PKIX
infrastructure has been operating as a security infrastructure for 15 years,
its flaws are reasonably well understood at this point. DNS on the other
hand is a non-security infrastructure that people appear to want to
immediately co-opt to duplicate functions of PKIX.

"What could possibly go wrong"


Given that the problem that instigated this proposal is mis-issue of a
certificate. It would appear to me that we should look at deploying controls
that reduce the probability of mis-issue of a certificate before we rush to
deploy a completely new validation scheme for certificates in the six month
timescale being proposed in this charter.

In particular, it would be rather useful to have controls of the form:

* Certificates only valid if issued into a certificate chain with specified
properties
* Obtain additional authentication according to protocol X and key Y.



On Tue, Oct 5, 2010 at 12:32 PM, Kemp, David P. <[e-mail]>wrote;wrote:

> You are confusing attack surface with vulnerability.  Without getting
> into technology specifics, if A .and. B must be successfully attacked in
> order to cause a problem, then having two systems can only reduce the
> vulnerability even though there are more places to attack.
>
> If the problem is availability, then the best strategy is redundancy -
> use multiple sources for a single information item.  If the problem is
> integrity, the best strategy is diversity - use different sources for
> different information items.  If either source gives the wrong answer
> you fail, but fail safely.  (Redundancy and diversity can be combined of
> course, but then combining rules such voting thresholds have to be
> specified).
>
> For the DNS/PKI case, if A is an IP address for a dnsname and B is a
> public key for a dnsname, then it is necessary to attack the sources of
> A and B in order to successfully spoof a named server.  If A and B come
> from the same system (e.g., DNS) it is necessary to attack only that
> system.  If they come from different systems (DNS and PKI) then it is
> necessary to attack both.  Attacking only one may cause an availability
> failure, but not an integrity failure.
>
> Dave
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Ben Laurie
>
>
> If I deploy the DNS solution, stating that DNS is authoritative, then
> my attack surface now excludes all CAs. How is that an increase in
> attack surface?
>
> Contrast with today's situation, where my attack surface is increased
> on a regular basis by the introduction of new CAs, without any
> consultation with me at all.
>
>


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