On Tue, Nov 05, 2013 at 05:01:54PM -0800, Chris Newman wrote:
> I have read draft-ietf-dane-smtp-with-dane-02.txt and support
> advancing it on standards track if three changes* are made to the
> document as mentioned in my comments below. I believe this is a
> plausible strategy to improve security/privacy for SMTP relay and is
> close to ready for publication.
Thanks for the feedback. The primary points of contention appear
to be:
- Objection to DANE TLSA for submission.
- Objection to requirement to match any of multiple peer names.
- Suggestion that SMTP servers not offer TLS if the configured trust
chain lacks a suitable TA.
- Objection to text recommending anonymous cipher support on
the server.
My response to each below:
- DANE for SMTP Submission
* This is good measure a response to RFC6409 which introduces
SRV records as a means to offer zeroconf MSA deployments.
With the client having no securely obtained name to check in
the peer certificate, the peer certificate is unusable, one
can check it is valid, but one check that it names the right
server.
My contention is that MUA + SRV is in the same boat as MTA + MX
and the only practical way to make either secure is DANE.
Once we have at least one use-case for MUA + DANE, there is
also the use case in which the server administrator and MUA
user prefer to use DANE. There needs to be standard for this,
and an SMTP + DANE RFC seemed like a fine place to cover this.
- Objection to multiple peer names.
* This was adopted from Tony's expired SRV draft. I agree with
the motivation to interoperate with existing practice. It is
already common in bilateral SMTP security configurations to
field certificates that match the recipient domain, not the
MX host. Public CAs even market (I may have misremembered
the name) Unified Messaging Certificates.
So DANE SMTP clients need to be prepared to encounter certificates
tailored to a pre-DANE world.
Postfix (widely deployed) supported multiple name values, even
before DANE. This is IMHO not a major obstacle.
- SMTP server chain sanity checks
* This is rather tricky. An SMTP server does not generally know whether
it is doing DANE or not, clients know whether they are doing DANE
when they obtain (or fail to obtain) appropriate TLSA records.
To determine whether it is missing a TA cert, a server would
have to look up TLSA records for all relevant domains, locate
the MX record that identifies it, obtain the TLSA RRset. If
that RRset has usage 2 entries, after (in the SNI use-case)
figuring out which chain applies to that domain, it then needs
to validate the chain to see whether the required TA is present.
I don't see ever implementing this for Postfix. What I did
implement is a command-line tool that allows one to probe SMTP
server TLS support and determine whether TLS works, including
tests of DANE verification when TLSA records are found.
Server operators should test their servers from a client that
is configured with zero trusted CAs and make sure that DANE
works there, when DANE TLSA records are published. We can
give some more specific guidance to server operators on testing
their deployment, perhaps in the ops draft, but I would not object
to additional overlap in the SMTP draft.
- Anon ciphers
* A substantial fraction of SMTP MTAs enable and will continue
to enable anon ciphersuites when not authenticating the server.
* The comment in the draft is recommending *server* server support
for these. If the client has already sent a HELLO message
with a bunch of anon ciphersuites, the server may as well
use one, and though it may prefer non-anon ciphers, its
TLS stack should not fail just because anon ciphers were
offered.
> The TLS protocol has interoperability problems if the client hello
> has too many cipher suites in it.
* This issue may have been substantially addressed yesterday,
see the the IETF TLS mailing list thread on ALPIN:
http://www.ietf.org/mail-archive/web/tls/current/msg10423.html
Avoiding client HELLO with length in [256,512) resolves the
SSLv2 vs. SSLv3 HELLO ambiguity.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
