Re: [dane] review of draft-ietf-dane-smtp-with-dane-02.txt

[Chris Newman <[e-mail]>]

Thanks for the thoughtful response!

--On November 7, 2013 17:10:06 +0000 Viktor Dukhovni 
<[e-mail]> 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