On Mon, Mar 04, 2013 at 11:34:27PM -0500, Paul Wouters wrote:
> While I also dislike the name check, which should not be required or
> looked at for non-CA use, it is not hard to generate a wildcard
> certificate.
Not all applications understand wildcard certificates, or even
correctly parse certificate content.
When the Moxie Marlinspike embedded NUL attack on CA name bindings
was published, Postfix was one the few applications not impacted,
since I already anticipated this problem and Postfix already had
checks for embedded NULs in ASN.1 strings.
The moral of this anecdote is not that the Postfix developers go
the extra mile, but rather that X.509 is a very complex standard
with many pitfalls, and anything that makes the application's job
easier is a big win.
The easiest way to check that you have the right certificate is to
not parse it at all, or parse it just enough to extract the public
key (this is generally directly supported by the SSL toolkit), and
then just compare that or a digest of it to the value bound by DANE.
The simplicity of the DANE binding leaves PKIX with its horde of
trust anchors, local versions of intermediate certs, servers that
fail to present all intermediate certs, depth limits, expiration
date arithmetic, name constraints, multitudes of name types,
critical extensions, ... in the dust.
It is almost a miracle anyone ever gets X.509 validation right.
>From the X.509 mess we get as many opportunities for insecurity as
opportunities for enhanced security.
> >My (not outlandish) view is that the legacy public CA X.509 PKI is
> >a sinking ship. There is little reason to entrench its semantics
> >into new protocols except as an optional transition aid.
>
> While I agree here, it is kinda strange to put in a selfsigned
> generated cert in DNS. If you go through the effort of putting in
> a TLSA, you can also generate a proper cert for the mailserver?
It is a historical accident (naive MIT senior thesis in the early
80's IIRC) that we're using publica CA PKI at all. We might have
had keys in DNS a lot sooner if X.509 were not an expedient crutch
for a while. IMHO DANE provides a mechanism to bind service end
points to public keys disguised as EE certificates only because we
need to work with the current installed base, not because there is
inherently something compelling about the existing "PKI".
> >Smaller certificates use less bandwidth. This is the sort of lean
> >and mean certificate (303 bytes of DER) I plan to deploy on MX host
> >MTAs (bare minimum extensions to support TLS key usage).
>
> Loking forward to bare public key support in gnutls :)
>
> Then there is no name binding, so everyone is happy!
Hooray, there is no name binding *inside the X.509 certificate*,
but the real name binding (DNSSEC TLSA record) remains.
-----
Speaking of name bindings, it would perhaps be useful to have DANE
support for SMTP clients that are MTAs (not people using MUAs) to
use client certificates to authenticate their EHLO names to servers.
Since clients are not a _port._tcp.<hostname> endpoint, we'd need
some fixed prefix (_smtpc for smtp client?) that would allow the
receiving MTA to check the DNS for:
_smtpc._tcp.<ehloname> IN TLSA
and verify the client's identity. This would enable scalable
TLS-based client authentication without public CAs. This supports
various outsourcing arrangements in which content provider or email
hosting service relays mail through a client's gateway for DKIM
signing, compliance archiving, ...
But this is a different thread, for another day.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
