On Sun, Sep 22, 2013 at 10:09:27AM -0700, Todd Lyons wrote:
> > I was hoping that Phil would get a chance to implement DANE support
> > for the next release. I don't know whether he has the requisite
> > free cycles.
>
> Phil is pretty bowed up; his availability is low.
>
> Viktor, is DANE strictly a resolver implementation? Or would support
> have to be added independently for each service that supports STARTTLS
> or TLS in general? Or both resolver side and each implementation?
> Reading the RFC, it seems like it would have to touch both.
The DNSSEC validation code can be delegated to the local resolver.
The code for validating the peer certificate chain given a DNSSEC
validated TLSA RRset (from the resolver) is a non-DNS problem, and
must be handled in application code, or in the supporting TLS
libraries. Given the specialized use of TLSA RRs with SMTP (no
support for certificate usages 0/1, ...) generic library code in
toolkits will likely be unsuitable for SMTP, even when made available
for generic DANE TLS applications.
So the upshot is that you need just a couple of lines of code to
support DNSSEC, and a few hundred lines of code to verify the peer
certificate chain against the TLSA RRs obtained securely from
DNSSEC.
In Postfix, the DNSSEC portion of DANE is delegated entirely to
the local resolver. An MTA administrator who wants to enable DANE
MUST configure a local (127.0.0.1, ::1 or both) DNSSEC validating
DANE cache. This frees Postfix from the burden of validating DNSSEC
responses.
The Postfix DNS client sets the "DO" (DNSSEC OK) bit in
the DNS request, and the validating resolver sets the "AD"
(Authenticated Data) bit in the response when the response is
"secure" (it discards "bogus" responses, so responses without "AD"
are "insecure").
When DANE is enabled and secure TLSA RRs are found, the Postfix
TLS driver enables an OpenSSL callback that preprocesses the peer
certificate chain. If the peer chain contains an ancestor of the
leaf certificate that matches a usage 2 (private CA) TLSA record,
an extended chain is constructed, in which the private CA's public
key is wrapped as a dynamically constructed internal intermediate
CA, which is signed by a dynamically constructed internal root.
The internal root replaces the OpenSSL root trust store, and the
entire chain is then verified in the usual way.
The reasons for the dynamic internal intermediate + root are:
- With "... IN TLSA 2 1 0 <SPKI>", the trusted public key of
the peer is provided in bare form, without a containing CA
certificate. In this case the peer does not have to provide
the corresponding CA certificate on the wire (it is TLS
server HELLO certificate chain). So Postfix constructs a
dynamic certificate around this key.
- The immediate child of the trust-anchor always contains
an issuer name, so the above CA's subject name cannot be
fixed, it must match the child's issuer name.
- The immediate child of the trust-anchor may contain an
authority key identifier extension which specifies the
issuer name of the authority (i.e. the grandparent name of
the child). Thus the above CA cannot be assumed self-issued
and it's parent CA's name cannot fixed, it must match the
authority key identifier name of the child (if present).
While in many cases the peer chain will contain the full CA
certificate, its parent certificate may not be present, and the
slightly more complex code is still required for the "2 1 0" use
case. To avoid bugs in rarely used code, the Postfix approach
was to always assume the worst, and pretend that all usage "2"
cases are bare public keys (by extracting the key and discarding
the cert if present) and treating all the cases identically!
https://en.wikipedia.org/wiki/Teakettle_principle
This simplifies the code, all cases use the same strategy.
--
Viktor.
