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

"Kemp, David P." <DPKemp@missi.ncsc.mil> Tue, 05 October 2010 16:32 UTC

Return-Path: <DPKemp@missi.ncsc.mil>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28CF23A6FA4; Tue, 5 Oct 2010 09:32:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.582
X-Spam-Level:
X-Spam-Status: No, score=-5.582 tagged_above=-999 required=5 tests=[AWL=1.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJbVxG1g+42q; Tue, 5 Oct 2010 09:32:47 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id AD6773A6FC8; Tue, 5 Oct 2010 09:32:47 -0700 (PDT)
Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id o95GXfBt000479; Tue, 5 Oct 2010 12:33:41 -0400 (EDT)
Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Oct 2010 12:32:21 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 5 Oct 2010 12:32:59 -0400
Message-ID: <C1A47F1540DF3246A8D30C853C05D0DA0341EC56@DABECK.missi.ncsc.mil>
In-Reply-To: <AANLkTimtc1aT0r+oTJYpjixTSiE+gwpORszjPYz7y7PE@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC
Thread-Index: Actj8IMQKtYXwe1DQHq0gJKQySimfAAshQ7Q
References: <AANLkTinRWJZr7huuG+Ovh3sCCUnVZAghggAzmq7g6ERx@mail.gmail.com><1285970705.1984.136.camel@mattlaptop2.local><AANLkTi=cD1E=QoD3uRyhHyd6bUSgd9_ibgdM5iy1+9TR@mail.gmail.com> <AANLkTimtc1aT0r+oTJYpjixTSiE+gwpORszjPYz7y7PE@mail.gmail.com>
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: "Ben Laurie" <benl@google.com>, "Phillip Hallam-Baker" <hallam@gmail.com>
X-OriginalArrivalTime: 05 Oct 2010 16:32:21.0859 (UTC) FILETIME=[E2916B30:01CB64AA]
Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@ietf.org
Subject: Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Oct 2010 16:32:50 -0000

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: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] 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.