DANE, DNSSEC, ..., Postfix, ...

[Viktor Dukhovni]

(2) There is a draft for MTA-to-MTA SMTP. In addition to saying "use
draft-ietf-dane-srv" (which covers most of what needs saying) it also
addresses the fact that RFC 3207 doesn't specify how to validate mail
server certificates.
http://tools.ietf.org/html/draft-ietf-dane-smtp

My perspective, is that any sane administrator of a cluster of
equal-preference MX hosts will use:

example.com. IN MX 0 mx1.example.com.
example.com. IN MX 0 mx2.example.com.
...
;
_25._tcp.mx1.example.com IN CNAME 3.1.1._dane._smtp.example.com.
_25._tcp.mx2.example.com IN CNAME 3.1.1._dane._smtp.example.com.
...
;
3.1.1._dane._smtp.example.com. IN TLSA 3 1 1 <public-key-fingerprint>

and the question of the contents of the certificate (beyond containing
the expected public key) becomes moot.

The same goes with certificate usage 1, in fact I plan to treat
"1" as a clue-deprived typo for "3". IMNSHO the domain owner is
expected to not publish DNS bindings to certificates that fail to
pass PKIX validation. For the same reason I plan to treat "0" as
a clue-deprived typo for "2". This substantially simplifies
implementation with no real reduction in security.

Given that the overwhelming majority of SMTP the minority of SMTP
servers that offer TLS do so with self-signed or otherwise not
verifiable certificates, it makes little sense with SMTP to at this
late stage jump on board the sinking public CA ship. Therefore,
I would suggest that the use of "3 1 1" DANE records should be
strongly recommended for SMTP servers over all other options.

The remaining state machine (when DANE support is enabled) bols
down to:

- If destination is subject to local TLS policy:

http://www.postfix.org/TLS_README.html#client_tls_policy

do that in preference to any DANE policy (except when that local
policy *is* to do DANE for that specific destination).

- If MX RRset bogus (including bogus NXDOMAIN/NODATA): tempfail
- If MX RRset insecure: do opportunistic TLS with plaintext fallback
- If MX RRset NODATA, impute a validated "IN MX 0 <nexthop-domain>"

- If validated MX records in hand, for each MX host look for
a validated _25._tcp.<hostname> RRset.
- If bogus (including bogus NXDOMAIN/NODATA), remove host from
MX list (tempfail if last host)
- If insecure, do opportunistic TLSA with this host
- Discard malformed/unusable TLSA RRs
- Apply remaining policy, or if none do opportunistic TLS with
plaintex fallback.

In all the above a RRset that results from a chain of CNAME expansions
is validated if and only if all the CNAME RRs are validated in
addition to the final result RR.

Is there any particular portion of the draft on which you would
like to see additional community input?

[Viktor Dukhovni]

http://tools.ietf.org/html/draft-ietf-dane-srv

One quick comment on Section 7.3 of the above. This section is
broken. Certificate name checks are *only* appropriate with
certificate usage 0 and 2, and are *never* appropriate with usage
1 and 3.

Furthermore, a client MUST NOT assume any semantics for any new
certificate usage values not known at the time of client implementation.

Multiple servers that do not share a single name can be reasonably
expected to share a single replicated key-certificate pair, bound
to the service by fingerprint alone. One should not need to re-issue
the certificate every time a new server is added to the cluster.

See section 4.1 of DANE (6698) which clearly states:

If a certificate association contains a certificate usage,
selector, or matching type that is not understood by the
TLS client, that certificate association MUST be considered
unusable....

Have the authors of draft-ietf-dane-srv bothered to read 6698?
Do they understand the certificate fingerprint use-case?

It seems to a naive observer that the answer to both is "no".

[Viktor Dukhovni]

Post by Viktor Dukhovni
- If insecure, do opportunistic TLSA with this host

I think you meant TLS here.

Yes, TLS, and on closer reading of draft-ietf-dane-srv, it is
"mandatory TLS" not "opportunistic TLS", but contrary to that spec,
the practicalities of email mean: *without PKIX* validation.

Post by Viktor Dukhovni
One quick comment on Section 7.3 of the above. This section is
broken. Certificate name checks are *only* appropriate with
certificate usage 0 and 2, and are *never* appropriate with usage
1 and 3.

If you have a certificate with a mismatched name it will fail validation
with non-DANE clients. So the another reason for keeping the name checks
in all cases (which I should add to the spec) is for more consistent
behaviour between old and new clients.

The long thread on the DANE list boils down to "no name checks for
certificate usage 3". Therefore, also not "name checks in all cases".

Post by Viktor Dukhovni
Multiple servers that do not share a single name can be reasonably
expected to share a single replicated key-certificate pair, bound
to the service by fingerprint alone. One should not need to re-issue
the certificate every time a new server is added to the cluster.

Maybe in current SMTP deployments, because SMTP certificate validation is
broken, but that isn't true for other protocols.

Actually, for all protocols with certificate usage 3. So with any
luck the spec will be revised accordingly.

Postfix will map usage 0 to 2, and usage 1 to 3, and Postfix DANE
documentation will strongly encourage administrators to only ever
generate "TLSA 3 1 1" records. These are least likely to break due
to incomplete trust-anchor lists on the sender side, or other common
barriers to PKIX validation that browser users can click-through,
but MTAs cannot.