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

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 16 Mar 2014 20:54:28 +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.

---

From: James Cloos <[email-masked]>
Date: Sun, 16 Mar 2014 18:45:20 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

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

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

That seems reasonable.

Some software stacks may make that difficult easily to accomplish.
At least in the short term.  But such libraries can be fixed.

So, +1.

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: [email-masked] (Martin Rex)
Date: Tue, 18 Mar 2014 00:33:25 +0100 (CET)

> 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.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Mar 2014 23:54:13 +0000

> 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.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 18 Mar 2014 12:21:10 -0400 (EDT)

> enforces the X.509 asserted validity period.

You can't because we now have EE certs that could only contain SBKI and
no other x.509 legacy.

Paul