[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.
- [keyassure] Objective: Restrictive versus Supplem… Eric Rescorla
- Re: [keyassure] Objective: Restrictive versus Sup… Paul Wouters
- Re: [keyassure] Objective: Restrictive versus Sup… Yoav Nir
- Re: [keyassure] Objective: Restrictive versus Sup… Stephen Kent
- Re: [keyassure] Objective: Restrictive versus Sup… Richard L. Barnes
- Re: [keyassure] Objective: Restrictive versus Sup… Richard L. Barnes
- Re: [keyassure] Objective: Restrictive versus Sup… Eric Rescorla
- Re: [keyassure] Objective: Restrictive versus Sup… Richard L. Barnes
- Re: [keyassure] Objective: Restrictive versus Sup… Michael Richardson
- Re: [keyassure] Objective: Restrictive versus Sup… James Cloos
- Re: [keyassure] Objective: Restrictive versus Sup… James Cloos
- Re: [keyassure] Objective: Restrictive versus Sup… Martin Rex
- Re: [keyassure] Objective: Restrictive versus Sup… Martin Rex
- Re: [keyassure] Objective: Restrictive versus Sup… Eric Rescorla
- Re: [keyassure] Objective: Restrictive versus Sup… Richard L. Barnes
- Re: [keyassure] Objective: Restrictive versus Sup… Jay Daley
- Re: [keyassure] Objective: Restrictive versus Sup… Eric Rescorla
- Re: [keyassure] Objective: Restrictive versus Sup… James Cloos
- Re: [keyassure] Objective: Restrictive versus Sup… Jay Daley
- Re: [keyassure] Objective: Restrictive versus Sup… Richard L. Barnes
- Re: [keyassure] Objective: Restrictive versus Sup… Martin Rex
- Re: [keyassure] Objective: Restrictive versus Sup… Eric Rescorla
- Re: [keyassure] Objective: Restrictive versus Sup… Warren Kumari
- Re: [keyassure] Objective: Restrictive versus Sup… Martin Rex
- Re: [keyassure] Objective: Restrictive versus Sup… Martin Rex
- Re: [keyassure] Objective: Restrictive versus Sup… Eric Rescorla
- Re: [keyassure] Objective: Restrictive versus Sup… Paul Wouters
- Re: [keyassure] Objective: Restrictive versus Sup… Paul Wouters
- Re: [keyassure] Objective: Restrictive versus Sup… Eric Rescorla
- Re: [keyassure] Objective: Restrictive versus Sup… Michael Richardson
- Re: [keyassure] Objective: Restrictive versus Sup… Richard L. Barnes
- Re: [keyassure] Objective: Restrictive versus Sup… Yoav Nir
- Re: [keyassure] Objective: Restrictive versus Sup… Michael Richardson
- Re: [keyassure] Objective: Restrictive versus Sup… Yoav Nir
- Re: [keyassure] Objective: Restrictive versus Sup… Martin Rex
- Re: [keyassure] Objective: Restrictive versus Sup… Martin Rex
- Re: [keyassure] Objective: Restrictive versus Sup… Yoav Nir
- Re: [keyassure] Objective: Restrictive versus Sup… Richard L. Barnes
- Re: [keyassure] Objective: Restrictive versus Sup… Martin Rex
- Re: [keyassure] Objective: Restrictive versus Sup… James Cloos
- Re: [keyassure] Objective: Restrictive versus Sup… Paul Wouters
- Re: [keyassure] Objective: Restrictive versus Sup… Paul Wouters
- Re: [keyassure] Objective: Restrictive versus Sup… Yoav Nir
- Re: [keyassure] Objective: Restrictive versus Sup… Yoav Nir
- Re: [keyassure] Objective: Restrictive versus Sup… Paul Wouters
- Re: [keyassure] Objective: Restrictive versus Sup… Jim Schaad