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

Seth David Schoen <schoen@eff.org> Tue, 05 October 2010 18:03 UTC

Return-Path: <schoen@eff.org>
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 B2C7A3A7079; Tue, 5 Oct 2010 11:03:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 8YOWogiFFpbW; Tue, 5 Oct 2010 11:03:26 -0700 (PDT)
Received: from mail1.eff.org (mail1.eff.org [64.147.188.4]) by core3.amsl.com (Postfix) with ESMTP id C456A3A6FB7; Tue, 5 Oct 2010 11:03:25 -0700 (PDT)
Received: from sescenties (localhost [127.0.0.1]) by mail1.eff.org (Postfix) with ESMTP id AC038BE099; Tue, 5 Oct 2010 11:04:25 -0700 (PDT)
Date: Tue, 5 Oct 2010 11:04:23 -0700
From: Seth David Schoen <schoen@eff.org>
To: "Kemp, David P." <DPKemp@missi.ncsc.mil>
Message-ID: <20101005180422.GA15277@sescenties>
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> <C1A47F1540DF3246A8D30C853C05D0DA0341EC56@DABECK.missi.ncsc.mil>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <C1A47F1540DF3246A8D30C853C05D0DA0341EC56@DABECK.missi.ncsc.mil>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: dnsop@ietf.org, saag@ietf.org, pkix@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 18:03:27 -0000

Kemp, David P. writes:

> 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.

In the case where an attacker controls the network, they can win
with B only, without A, because they can perform an active attack
even when the client knows the correct IP address for the server.

Consider

http://www.ex-parrot.com/~pete/upside-down-ternet.html

which only attempts to attack HTTP without TLS.  But notice that
it would work correctly even with DNSSEC because it does not rely
on misleading the client about the server's IP address.

In this threat model, attacking the source of A is not necessary
for spoofing a TLS-enabled server, but attacking the source of B
is.  This threat model could apply realistically to many public
networks, particularly because the attacker need not be the
network's legitimate owner in order to control the network (for
instance, through compromised routers, DHCP spoofing, or ARP
spoofing).

In this model, getting the service's correct public key to the
client is necessary and sufficient all by itself.