On Fri, Feb 14, 2014 at 04:48:32PM -0800, Paul Hoffman wrote:
> Viktor's view gives us good MITM protection if the DNS channel
> is not broken and the client knows the DNSSEC status of its query.
> It also causes messages to be lost if there is an operational
> problem or even an unexpected mis-match on the crypto desires of
> the client and server. It also assumes that the person running the
> DNS server for a name is in active contact with the person operating
> the SMTP server.
Some comments on the above.
- When authetication fails, the DANE SMTP draft specifies
"delay" (aka defer, queue, ...) not bounce. Provided the
receving system operator fixes the server configuration in
a reasonably timely manner, no mail is lost.
- Crypto parameter mismatch for SMTP TLS is quite rare. The
only common problems are:
* Microsoft Exchange 2003 only looks at the first 64 cipher
suites in the TLS client's SSL HELLO. It has a broken
3DES implementation that mishandles CBC padding. SMTP
clients that support TLS 1.2 typically have more 64 cipher
suites stronger than RC4-SHA and TLS connections to
Microsoft Exchange 2003 often fail after negotiating
3DES-CBC. While such server are still found here and
there, operators of these would be foolish and unlikely
to publish TLSA records.
* Some Debian "squeeze" systems have an Exim SMTP client
that was inadvisably patched by Debian to require 2048
bit or longer EDH primes. These fail to handshake with
many servers that employ 1024 bit EDH primes. These SMTP
clients do not implement DANE. The patch has been reverted
in newer Debian releases. When Exim supports DANE, we
can reasonably hope that Debian won't repeat their mistake.
- As for "active contact", yes active contact is required after
all to publish the TLSA record in the first place. However,
at tiny sites (say dukhovni.org) whose SMTP server certificate
is long expired, but still pinned and thus valid enough for
my MUA, "active contact" is a non-issue. Simiarly, with
DANE-EE(3) there is no need for "active contact" (though I
admittedly am in "active contact" with myself).
No "active contact is required" with DANE-TA(2). The DNS
folks and the folks operating the domain's CA publish new
TLSA RRs for the latest CA keys from time time. They issue
new certs to the peons operating the SMTP server, these just
work, because the TLSA RRs are CNAMEs pointing at the centrally
managed TLSA RRset.
Thus there are two reasonable models, that typically match
smaller and larger organizations respectively, and don't
impose undue operational burdens. These are described in
the SMTP and ops drafts.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
