[dane] DANE-EE(3) certificate matching rules?

Viktor Dukhovni <viktor1dane@dukhovni.org> Sun, 16 March 2014 20:54 UTC

Return-Path: <viktor1dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7F01A01F9 for <dane@ietfa.amsl.com>; Sun, 16 Mar 2014 13:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RU44-qAJ2GpD for <dane@ietfa.amsl.com>; Sun, 16 Mar 2014 13:54:37 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id C53911A01E4 for <dane@ietf.org>; Sun, 16 Mar 2014 13:54:36 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 827372AADF5; Sun, 16 Mar 2014 20:54:28 +0000 (UTC)
Date: Sun, 16 Mar 2014 20:54:28 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140316205428.GG24183@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/8EfkLUuC6E2qp7NmMuCuVyTWs2E
Subject: [dane] DANE-EE(3) certificate matching rules?
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Mar 2014 20:54:40 -0000

We've previously agreed on cu=DANE-EE(3) obviating name checks,
since the TLSA base domain with port and protocol prefix is in fact
a more specific binding of the service end-point and public key
than any name in the certificate, and (perhaps more so) because
this dramatically simplifies virtual hosting.

In the OPs draft I went further and stated that verification of
the DANE-EE(3) end-entity certificate stops at matching it against
the TLSA record, and its content MUST otherwise be ignored.  This
subsumes at least checks of the expiration date and also the EKU,
both of which are essentially superseded by the TLSA RR.

I may have gone a bit further than necessary.  The main goal is to
make DANE authentication usable in protocols with no user to "click
OK".  To this end I want to avoid the most common operational
failures with PKIX.  Therefore I propose that:

    - In addition to name checks, expiration checks also be
      performed via the TLSA RR signature lifetime, rather than
      the certificate expiration date.  The TLSA record is updated
      frequently as the DNSSEC zone is periodically re-signed.  This
      ensures that there are no surprise expirations.  Certificates
      can be replaced at the operator's convenience.

    - Though the EKU is technically superseded by the TLSA RR type,
      which implies a TLSA usage, getting this wrong would be
      discovered immediately by the server operator, and quickly
      fixed.  There is no need to complicate implementations by
      special-casing DANE EKU processing.  Similarly with the key
      usage, and other fields.

Therefore, the final proposal for DANE-EE(3) is that only name
checks and expiration checks are out of scope.  This applies whether
the selector is Cert(0) or SPKI(1).  However, when *all* TLSA records
are "IN TLSA DANE-EE(3) SPKI(1) ?", implementations that support the
proposed bare public key TLS extension, may signal that extension,
in which case if the server cooperates, in effect the rest of the
certificate is ignored (in fact never transmitted).

Any comments? Can the above be the final consensus on this topic?

-- 
	Viktor.