>>>>> "IF(" == Ian Fette (イアンフェッティ) <[email protected]> writes:
IF(> Ondřej, I might be getting it wrong, but since our CA is cross-signed by
IF(> another CA, the chain that most clients will build will be rooted in
IF(> something else.
2 can point at any cert in the full chain other than the ee cert. The
client is expected to verify from the ee to the cert specified in the 2,
and then verify that /that/ cert matches the tlsa.
You can also do that with a 0. If you use 0, then clients are typically
expected to do the above, but *also* verify the full chain just as they
would w/o DANE.
Pointing at the google ca with type 0s would be fine for everything you
serve at a fixed port over tls or dtls, given that you have a corp CA
which has been signed by a well-known root CA. But only if clients
which do not know the typical ca-certificates.crt choose to pretend that
the type 0 were a type 2, as Victor’s draft recommends. And as his
postfix code does.
Some suggest using a CNAME to point at a single TLSA RR to improve
caching (the CNAME RRs require fewer bits than the TLSA, so a lot of
CNAME RRs pointing at one TLSA probably is better than a lot of TLSA RRs
with identical content. (Hint to self.)
Most smtp client admins do not bother to configure the list of CAs, so
most could not do full type 0 or type 1 verification. Some of us do,
however, configure it, do check the offerred certs when sending mail,
but cannot, yet, require that they pass. There are too many MXs which
can only to untrusted tls.
Since I point my outgoing postfix at:
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
I get logs like:
Trusted TLS connection established to
gmail-smtp-in.l.google.com[2607:f8b0:4002:c04::1b]:25:
TLSv1.2 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
(Interesting that the MXs still prefer rc4; the other goog TLS services
recently switched to negotiating TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256.)
But cannot demand Trusted, due to sites like:
Untrusted TLS connection established to
mail.ZZZZZZ.org[NNN.NNN.NNN.NNN]:25:
TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
or:
Untrusted TLS connection established to
mx.ZZZ.org[NNN.NN.NN.NN]:25:
TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)
(names elided to protect the untrusted :).
The inability to demand Trusted is likely why most do not bother to
configure the CAfile. In fact it is only in that last year or so that
most of my outgoing mail has been to MXs which even offer starttls.
DANE should help that.
-JimC
--
James Cloos <[email protected]> OpenPGP: 1024D/ED7DAEA6
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
