Thanks for the thoughtful response!
--On November 7, 2013 17:10:06 +0000 Viktor Dukhovni
<[email protected]> wrote:
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.
I think you meant RFC 6186. Putting on my mail end-user hat, I'm not
sufficiently concerned by active attacks during account setup that I'd be
willing to spend more money on a mail client to get protection for that.
Mail clients that implement 6186 can do the SRV lookup insecurely and then
use traditional TLS with the resulting hostnames embedded in the account
profile from then on. I believe that will be good enough for most end users
and MUA vendors. How many people do you know who verify the SSH fingerprint
the first time they connect to a server?
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.
What evidence do you have that DANE is practical for MUAs? Do you have any
significant MUA vendors who want to implement DANE for submission?
If RFC 6125 SRV validation deploys in SSL stacks, then MUAs could implement
SRV validation for submission with a single function call. The chance an
MUA vendor will instead do all the work of embedding a new DNS library to
do DNSSEC and DANE seems remote to me.
You do have evidence DANE for MTA + MX is practical because you've
implemented it and other MTA vendors are paying attention. There also isn't
a better option that includes server authentication for the deployed MX
infrastructure. Many MTAs already have an embedded DNS library anyway for
multi-threaded MX lookups so upgrading it to support DNSSEC seems plausible.
I've been in the email standards world for quite a while and this sort of
client/server deployment asymmetry is annoying and frustrating when trying
to make the infrastructure better, but it's also reality.
- 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.
I think Postfix uses OpenSSL. Our MTA uses NSS. The basic certificate
validation API in NSS takes a single name, and I haven't yet investigated
the extent to which it has callbacks to support multiple names. I generally
consider NSS the #2 open source SSL library in terms of deployment as it's
used in Thunderbird and Firefox as well as elsewhere. Anyway my concern is
that multiple names could be a deployment barrier. So if there's a way to
write the standard that didn't require multiple names it might be easier to
deploy the standard. However, if it's necessary to support two names to
make the model work, then it might be worth additional investigation of how
big a barrier it will be and if that barrier can be mitigated. I'll take an
action item to investigate the NSS API further to see how easy it is to
work around that problem.
- 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.
Point taken. I withdraw the suggestion.
- Anon ciphers
* A substantial fraction of SMTP MTAs enable and will continue
to enable anon ciphersuites when not authenticating the server.
I have no problem with this. Those MTAs are free to make that choice.
* The comment in the draft is recommending *server* server support
for these.
Why does this draft need to recommend them? It's inviting unnecessary
problems and disrespect for other recommendations in the draft.
I work on the SSL stack integration for our Messaging Server for
IMAP/POP/SMTP/LDAP/etc. I want to keep configuration of that stack as
simple as possible to avoid inadvertent security configuration errors.
Having a different set of ciphers that are enabled for different purposes
makes the product unnecessarily complicated and increases the chances of a
security configuration or coding error. I do allow the site admin to do
that with configuration if they really want to, but there will be a single
default set of ciphers enabled for all uses of SSL/TLS in our product and
it won't include the anonymous ciphers. I wouldn't consider changing that
because I don't want to explain it in the documentation nor take the risk
I'll make a mistake and enable the anon ciphers when they're inappropriate.
It can be argued that the presence of the anon ciphers in a TLS stack is a
security design error. It's hard enough to get certificate validation right
so the server is authenticated (far too much code ignores certificate
validation failures). But if it's also necessary to double-check the list
of enabled ciphers to make sure authentication works when it's needed,
that's just asking for more broken security in the wild. There was a
discussion on the NSS developers list about removing the anonymous ciphers
from that library. I don't recall the outcome of the discussion, but I'd
support their removal simply on the basis that less code is almost always
safer. And if they're not in the SSL library they won't be enabled and any
recommendation you put in the draft will be ignored.
You also might get challenges during IETF last call on this topic for
various reasons. That's somewhat less likely now the general attitude in
the IETF is more supportive of opportunistic encryption after recent
events. But I'd prefer to see this document finished sooner rather than
later, so let's drop this unnecessary advice when it's easier to do so
rather than later in the process where it can take longer.
As a suggestion: the draft might recommend servers log the cipher suite and
note that if an anonymous cipher suite is negotiated that the server's log
will then indicate no authentication was performed. That's true and
non-controversial.
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.
Glad to hear that!
- Chris
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
