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.
- [dane] DANE-EE(3) certificate matching rules? Viktor Dukhovni
- Re: [dane] DANE-EE(3) certificate matching rules? James Cloos
- Re: [dane] DANE-EE(3) certificate matching rules? Martin Rex
- Re: [dane] DANE-EE(3) certificate matching rules? Viktor Dukhovni
- Re: [dane] DANE-EE(3) certificate matching rules? Paul Wouters