On Sun, Jan 13, 2013 at 10:08:50AM -0500, Wietse Venema wrote:
> > When can we expect a Postfix release, that will support DANE
> > protocol ?
>
> A new feature is implemented when there is the time and the need
> to do so. Pluggable features such as DKIM and policies could be
> added in one development cycle, while more invasive features such
> as DSN and MIME were added in the course of multiple cycles.
The DANE specification is still a bit bleeding edge. Paragraph 4 of
https://tools.ietf.org/html/rfc6698#section-1.3
states
... Note that this document does not cover how to associate certificates
with domain names for application protocols that depend on SRV, NAPTR,
and similar DNS resource records. It is expected that future documents
will cover methods for making those associations, and those documents
may or may not need to update this one.
Since MX records used with SMTP are essentially a simple form of
SRV records, there is perhaps not yet a clear specification for
associating TLS certicates with SMTP servers.
SMTP with TLS has not received much attention from the IETF. There
is little discussion of the interaction between certificate names
and MX records in <https://tools.ietf.org/html/rfc3207#section-4.1>:
- A SMTP client would probably only want to authenticate an SMTP
server whose server certificate has a domain name that is the
domain name that the client thought it was connecting to.
- A publicly-referenced SMTP server would probably want to accept
any verifiable certificate from an SMTP client, and would possibly
want to put distinguishing information about the certificate in
the Received header of messages that were relayed or submitted
from the client.
A host may provide both HTTPS and SMTP services, and may reasonably
not want or be able to use the same (private-key, public cert) pair
for both HTTPS and SMTP. However, the traditional name binding in
PKIX X.509 certificates is to a hostname, not a (service, hostname)
pair. Thus, while one may expect that SMTP server certificates should
have a subjectAltName of:
_smtp.<hostname>
as in https://tools.ietf.org/html/rfc4985#section-2, in practice
no SMTP certificates bear such (subjectAlt) names, and no SMTP clients
expect them.
Finally, there is not yet a widely deployed client API for DNSSEC.
The legacy BSD libresolv does not provide any DNSSEC information.
An SMTP client that wishes to use DANE must verify that the MX
RRset it obtained is protected by DNSSEC and also that any
certificate binding information obtained via DNS is protected
by DNSSEC. This requires a standard API for secure DNS lookups.
So I don't expect immediate progress on this front, but partial
progress can perhaps be made. Postfix already supports matching
peer-certificates by their certificate or public-key fingerprint
(on the assumption that the selected digest is immune to second
preimage attacks so given a fingerprint it is no easier to construct
a matching certificate than a matching public key).
What we don't yet have, but will be needed for DANE, is support
for specifying a trust-anchor (root CA) fingerprint, so that
a per-site basis one can specify which root CA should be used
to verify the peer certificate.
I've been thinking of adding such an attribute to the tls_policy
table for some time. With this, the Postfix tls policy engine is
capable of supporting all the TLSA Certificate Usage Fields specified
in <https://tools.ietf.org/html/rfc6698#section-2.1.1>.
So it is perhaps time to add support for root CA fingerprints.
There is a subtle issue to consider. There is a somewhat perverse
distinction in section 2.1.1 between a "CA constraint" and a "trust
anchor assertion". The former requires that the verifier already
trusts the CA in question, and merely restricts the choice of
already trusted CAs, while the latter asserts a new trusted CA.
I see no need to support this distinction, either way we trust
the peer certificate it if it is signed by the CA in question,
and if we didn't already have the given CA as a trusted root CA,
the peer's DNS is free to "assert" it rather than "constrain" it.
Why would a peer ever want to be authenticated only by sites
that already trust its chosen CA and no others, rather than
by all sites capable of supporting DANE? So I would ignore
the distinction between certificate usage 0 and 2 (and
similarly 1 and 3).
In any case, I propose that we add support for root CA fingerprint
matching to the Postfix TLS engine allowing verification of trust
chains that contain a matching, possibly not a-priori trusted, root.
With this it becomes possible to map the results of a DANE DNS lookup
to a Postfix TLS policy. The rest is just additional glue to compute
such a policy on the fly when appropriate DNS APIs are broadly available,
and corresponding records are obtained via DNSSEC.
Concretely, to support DANE, we need two additional attributes in
the policy table, one to override the smtp_tls_fingerprint_digest,
so as to support <https://tools.ietf.org/html/rfc6698#section-2.1.3>
and another to specify the root CA fingerprint (which is computed
from the full certificate is that is provided in DNS).
So when a CA is involved (certificate usage 0 or 2) the imputed
TLS policy would be:
example.com secure \
digest=sha-256 \
rootca=<some-fingerprint> \
rootca=<another-fingerprint> ... \
match=<already-supported-match-syntax>
and when a CA is not involved (certificate usage 1 or 3) the imputed
TLS policy would be:
example.com fingerprint \
digest=sha-256 \
match=<fingerprint> \
match=<another-fingerprint> ...
The DANE specification potentially supports mixed security models,
wherein some of the elements of a TLSA RRset specify usage 0 or 2,
and others usage 1 or 3. This is not easily accomodated by Postfix
at this time, since the TLS library supports exactly one of the
two security models for a given connection.
I would be inclined to ignore usage 0 and 2, when 1 or 3 is present,
since given the expected peer certificate, there is no need for
any CAs.
Comments?
--
Viktor.
