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

Viktor Dukhovni <viktor1dane@dukhovni.org> Mon, 17 March 2014 23: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 75D701A01E1 for <dane@ietfa.amsl.com>; Mon, 17 Mar 2014 16:54:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 QwCvrbA29J-8 for <dane@ietfa.amsl.com>; Mon, 17 Mar 2014 16:54:22 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id C45551A0325 for <dane@ietf.org>; Mon, 17 Mar 2014 16:54:22 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 510D22AB274; Mon, 17 Mar 2014 23:54:13 +0000 (UTC)
Date: Mon, 17 Mar 2014 23:54:13 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140317235413.GN24183@mournblade.imrryr.org>
References: <20140316205428.GG24183@mournblade.imrryr.org> <20140317233325.601E81AC59@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140317233325.601E81AC59@ld9781.wdf.sap.corp>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/wki5r-PyXRDcoutrJ9gWCIhdPc0
Subject: Re: [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: Mon, 17 Mar 2014 23:54:25 -0000

On Tue, Mar 18, 2014 at 12:33:25AM +0100, Martin Rex wrote:

> > 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.
> > 
> > Any comments? Can the above be the final consensus on this topic?
> 
> I strongly dislike this idea, and would really appreciate instead
> a requirement that any X.509 certificates that are generated for use
> with DANE-EE(3) *MUST* be generated with a sufficiently liberal
> validity period that interop is not going to break if a DANE client
> enforces the X.509 asserted validity period.

I sympathize with the instinct.  The problem is that the longer
that interval is, the greater the surprise that the (long forgotten)
certificate has expired.

At least with my proposal the expiration can be used as a kinder-gentler
reminder to the server operator that it might be a good time to
replace the cert (often what happens with many PKIX certs that get
replaced in a hurry shortly *after* expiring).  With DANE-EE(3),
the server operator can audit his systems and note that some certs
are overdue for replacement.

Using the continued publication of the TLSA record in DNS as
continued validity of the certificate is much simpler, and avoids
operational difficulties that might otherwise derail adoption of
the protocol.  Having a protocol that is actually used is I think
the primary goal.  At the moment MTA SMTP clients ignore TLS certs,
names, expiration dates and all (and often use anon cipher-suites).

Decoupling the expiration from the certificate, makes operational
errors less likely.  Note that with "3 1 1" and "3 1 2" (which are
likely to be the most widely used), the expiration is not even
covered by the TLSA digest, and the certificate expiration can be
freely modified by anyone, without any objection from the verifier.

In other words, with "IN TLSA 3 1 ?", the expiration field is
provably superfluous.  With "IN TLSA 3 0 1" it arguably represents
the original intent of the publisher (long forgotten by the time
expiration rolls around).

Our new security protocols will cut some corners and break with
the past, where necessary, to enable broad adoption.  A protocol
that is too fragile won't get adopted. The proverbial "perfect" as
the enemy of the "good".

-- 
	Viktor.