[keyassure] Objective: Restrictive versus Supplementary Models

Eric Rescorla <ekr@rtfm.com> Wed, 30 March 2011 08:47 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD05C28C101 for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 01:47:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.94
X-Spam-Level:
X-Spam-Status: No, score=-102.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 Z6nma9LpLK37 for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 01:47:14 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C134228C0CF for <keyassure@ietf.org>; Wed, 30 Mar 2011 01:47:14 -0700 (PDT)
Received: by mail-iw0-f172.google.com with SMTP id 39so1175530iwn.31 for <keyassure@ietf.org>; Wed, 30 Mar 2011 01:48:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.136.138 with SMTP id u10mr916447ict.104.1301474933642; Wed, 30 Mar 2011 01:48:53 -0700 (PDT)
Received: by 10.42.217.2 with HTTP; Wed, 30 Mar 2011 01:48:53 -0700 (PDT)
Date: Wed, 30 Mar 2011 10:48:53 +0200
Message-ID: <AANLkTik1Uzd8XSZzopBBDHywrhSjsBQYxC91BZXdkMwg@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: keyassure@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [keyassure] Objective: Restrictive versus Supplementary Models
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Mar 2011 08:47:15 -0000

To follow up on my comments at the microphone, there are two potential
objectives for
technology of this type:

1. Protecting against CA mis-issue (as in CA/cert lock).
2. Allowing TLS to work without getting a certificate from one of the
established trust
anchors.

In the first case, the idea would be that the relying party would go
through its ordinary validation
logic and if that failed, would reject the certificate. However, if
the validation succeeded,
it would check DNS and if that check failed, would then reject the
certificate. Only if both
checks succeeded would the certificate be accepted. [0] The objective
of this type of
mechanism would be simply to defend against unauthorized certificate issuance.
Note that in this case, the DANE data need not be DNSSEC secured,
because an attacker
who tampers with it will solely be able to cause a connection failure,
and in many cases
(TLS, SSH, etc.) an attacker with those capabilities can tamper with
the A record and
block the connection that way.

In the second case, the intention is to allow clients to effectively
bypass the existing trust
hierarchy by injecting a new trust point via the DNS. Thus, either the
certificate validation
simply will not be used at all (in the case where a terminal
certificate is provided) or will be
used up to a newly inserted trust anchor. In either case, the
presumptive rationale here
is that it's too inconvenient to deal with the existing CAs and that
DANE will be easier.
This version of DANE *does* need to be protected via DNSSEC because tampering
with these records allows the attacker to impersonate the
authenticating party to the
relying party.


The draft to some extent conflates these two objectives, since it
*both* injects a new trust
anchor and restricts the list of potential certificates. It does not
allow you to simply restrict
the list of CAs/certificates without also injecting a new trust point.


Opinion follows:
For my money the most important driving use case for this work is the
first case, for two
reasons. First, it's the more pressing problem since it's not really
*that* hard to get a
certificate from one of the existing CAs, but this also means that we
have to worry about
mis-issue by misbehaving CAs, as we have recently seen. Second, the
incremental deployment
story is much easier, since clients which don't speak DANE will just
not be protected against
attack, whereas in the second case clients which don't speak DANE will
experience certificate
errors when connecting to a DANE-only site.

-Ekr


[0] The checks can be done in either order. This is only for clarity.