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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
