Re: [keyassure] Objective: Restrictive versus Supplementary Models

"Richard L. Barnes" <rbarnes@bbn.com> Wed, 30 March 2011 12:16 UTC

Return-Path: <rbarnes@bbn.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 13BA428C108 for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 05:16:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.541
X-Spam-Level:
X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, 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 pIBACKLyOoRb for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 05:16:42 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 1FD2B3A6947 for <keyassure@ietf.org>; Wed, 30 Mar 2011 05:16:42 -0700 (PDT)
Received: from [128.89.255.137] (port=58478 helo=[130.129.17.55]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1Q4uLs-000IFJ-Ft; Wed, 30 Mar 2011 08:18:20 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <AANLkTik1Uzd8XSZzopBBDHywrhSjsBQYxC91BZXdkMwg@mail.gmail.com>
Date: Wed, 30 Mar 2011 14:18:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com>
References: <AANLkTik1Uzd8XSZzopBBDHywrhSjsBQYxC91BZXdkMwg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.1082)
Cc: keyassure@ietf.org
Subject: Re: [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 12:16:43 -0000

I agree with Ekr and Steve that these are the right goals.  I don't have any further goals to add.  Just trying to re-state in bullet-point form:

1. Cert-lock / CA-lock
1.1. Use case:
1.1.1. Client initiates TLS connection and gets server cert chain
1.1.2. Client performs normal TLS/PKIX validation on cert chain
1.1.3. Client retrieves DANE records from DNS
1.1.4. DANE records specify EE or CA certs that MUST be present in cert chain
1.1.5. Client verifies that TLS cert chain meets DANE constraints
1.2. Security goal: Defend against issuance of other certs for this domain
1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause connection failure

2. Domain-managed authentication
2.1. Use case:
2.1.1. Client retrieves DANE records from DNS
2.1.2. DANE records specify Trust Anchors for PKIX certificate validation
2.1.3. Client adds DANE CA certs to TA store (optionally, drops all others)
2.1.3. Client initiates TLS connection and gets server cert chain
2.1.4. Client performs normal TLS/PKIX validation on cert chain
2.2. Security goal: Allow TLS to work without pre-configured TAs
2.3. DNSSEC REQUIRED; attacker can insert bogus TAs





On Mar 30, 2011, at 10:48 AM, Eric Rescorla wrote:

> 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 mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure