On Tue, Apr 16, 2013 at 05:24:50PM -0700, Paul Hoffman wrote:
> > Can I expect server operators to provide the TA certificate in the
> > TLS handshake server chain? If so on what basis? Their incisive
> > logical reasoning ability?
>
> Operational guidance is always welcome. We have some of that in
> the TLSA spec, but more would be useful.
If there is root for a new section in the specification that covers
operational guidance, and if you prefer downgrades the MUST to a
SHOULD (explaining when, ...) I guess I can live with that. Would
that be agreeable?
> > If I can't then usage 2 digests are "unusable". Shipping code that
> > makes mail delivery fail to RFC conformant peers is not particularly
> > attractive.
>
> Serious question: does your code somehow make sure that every
> SMTP client and every SMTP server can always agree on ciphers?
Not a single report of such problems comes to mind (due to incompatible
cipher settings) in over a decade of reading the Postfix users list.
Unlike HTTP servers, the tweaking of ciphersuites in SMTP is rather
rare and is strongly discouraged.
http://www.postfix.org/postconf.5.html#smtpd_tls_ciphers
http://www.postfix.org/postconf.5.html#smtpd_tls_mandatory_ciphers
http://www.postfix.org/postconf.5.html#smtp_tls_ciphers
http://www.postfix.org/postconf.5.html#smtp_tls_mandatory_ciphers
Postfix SMTP clients enable every cipher supported by the underlying
library except "export" or "low-grade" ciphers when TLS is mandatory
(as it would be with DANE).
A lot of care went into designing the cipher controls to make them
self-tuning to sensible defaults and to give users a small number
of simple safe options rather than expose them to the rather complex
OpenSSL cipherlist language.
So yes, in fact it *does* make sure that incompatible cipher settings
don't occur, though of course concerted effort to aim shotgun at
foot can ultimately succeed.
> (This is, of course, impossible.)
In theory impossible, in practice, possible through careful
user-interface design.
> If not, how does that differ from
> a PKIX administrator doing something stupid like only handing out
> the hash of a public key instead of the public key? These two
> situations can be prevented in the same way and have the same dire
> consequences if the operators mess up.
Postfix has always worked robustly with default settings. Neither
Wietse nor I have any plans to change that. Will enabling support
for "2 1 1" and "2 0 1" DANE TLSA RRs leave Postfix robust? What
default setting would you choose for your users if you were
maintaining Postfix and why?
http://vdukhovni.github.io/postfix/postconf.5.html#tls_dane_trust_anchor_digest_enable
Once a particular combination of TLSA RR fields is supported,
servers that publish these will only receive mail if they are
authenticated, otherwise mail stays in the sender's queue.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
