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

[Viktor Dukhovni <[e-mail]>]

On Thu, Nov 07, 2013 at 05:32:26PM -0800, Chris Newman wrote:

> >- 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.

Yes, sorry.

> 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.

It makes little sense to deploy SRV records, if all that happens
is that the client remembers them after a single lookup and can
never change them.  In 6186 the client retries the SRV lookup
whenever a secure connection fails.  This is a mistake, the connection
might not fail, and yet the client may reach the wrong place, and
find its IMAP account empty, (then purge its local cache, oops, ...)

I understand why the authors of 6186 wanted SRV caching, the SRV
lookup step was insecure.  With DANE, we can do better, and we
can protect subsequent reconfiguration when a MITM attack causes
the client to try reconfiguration.

I am not telling MUAs to do DANE.  I am telling them HOW to do
DANE.  I am encouraging them to do DANE to secure 6186 if they do
6186.  Likely for some time they will do neither 6186 nor DANE.


> >     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?

Practical is only a matter of code.  Once decent DANE support is
in TLS toolkits it will be easy for MUA authors to add DANE support
if they so desire.  This is not yet as easy as it should, but there
is no rush for MUA authors to adopt DANE.

> 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.

It is not possible to securely validate SRV lookup results without
DNSSEC.  We should not confuse "SRV-ID" subjectAltName values
(service@host) with SRV record hostname indirection.  There is
nothing in 6125 that addresses the problem of SRV record indirection
if the TLS peername is understood to be that of the target host,
not the hosted domain.

The only way to support hosting with certificates that match the
hosted domain is with SNI, which scales very poorly.  So when a
domain's mail (including submission) is hosted by a provider, it
should not be necessary for the domain to constantly feed the
provider with PKCS#12 key-pairs.  DANE makes this unnecessary.

> >     Postfix (widely deployed) supported multiple name values, even
> >     before DANE.  This is IMHO not a major obstacle.
> 
> I think Postfix uses OpenSSL.

Correct.

> 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.

I think this is important, otherwise verification of the MX (or
SRV) hostname alone fails to inteperate with UC certificates.  So
even if this requires more effort with NSS, that effort will be
necessary, possibly by extending NSS to support this across the
board, rather than asking each application to add code for this.

> >    * The comment in the draft is recommending *server* server support
> >      for these.

Well I definitely want to document that servers should definitely
not fail when a client presents anon ciphers.

> Why does this draft need to recommend them? It's inviting
> unnecessary problems and disrespect for other recommendations in the
> draft.

Because I've run into ignorant auditors who cargo-cult the same
nonsense about anon ciphers being insecure with no appreciation
for context.  An RFC that provides cover for people who know better
is a community service.

While indeed anon ciphers expose clients to MITM risk (unless
protected by a robust inner authentication protocol with channel
binding), they DO NOT expose servers to any risk, indeed they expose
in server logs the fact that clients were risking MITM attacks,
without introducing any possibility of MITM attacks.

I have no sympathy for the view that this is too nuanced a point
to explain to users and that we need to pretend that anon ciphers
are actually a problem on servers.  Not offering anon ciphers on
servers (where they don't hit the wire causing no interop cost) is
just burying one's head in the sand and feeling secure because you
don't see the dangerous MITM monster.  Once the client sends anon
ciphers the deed is done.

Postfix SMTP servers only suppress anon ciphers when client certs
are required, since in that case, the protocol requires that the
server start with its own cert.

> 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.

My assertion (based on logic rather than habit) is that *ALL* TLS
servers should enable anon ciphers unless they solicit client certs
in the initial handshake (in which case they have no choice).

> 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.

That's OK, I don't see a MUST in my draft.  I am willing to replace
the normative "SHOULD" with a neutral "should typically", if that
resolves the issue.  I am more interested in giving servers operators
candid advice about what that choice means than in forcing their hand.

    - Don't fall over when the client enables anon ciphers
    - Do consider enabling them on the server, your logs will tell
      you which clients enable anon ciphers (thus definitely don't
      e.g. do DANE, ...)

> 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.

Your product, your call.

> It can be argued that the presence of the anon ciphers in a TLS
> stack is a security design error.

This argument is simply wrong (cargo-cult burying of head in sand).

> You also might get challenges during IETF last call on this topic
> for various reasons.

I'm not too worried.

> 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.

With most TLS toolkits servers don't see what the client offered
(many ciphers) they see only what the toolkit agreed to!  It is
impossible to log an agreement on an anon cipher unless the server
agrees to one.   That's the whole point, and I do want to see the
cipher-suite in the logs.  Statistics about cipher-suite use are
very useful.  The above suggestion is basically what I wrote,
perhaps we can make that more clear:

    The purpose of server-side anon cipher support is forensics.
    The client is not authenticating the server, so no certificate
    is sent to mask this fact, and this is logged.

Clients SHOULD NOT use anon ciphers without good reason (e.g.
clearly defined opportunistic use-cases with no use of unverified
certs for pinning, ...).

> >>	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!

Though there are still some Windows 2003 Microsoft Exchange servers
(a small minority but reported from time to time) that fail when RC4-SHA
or RC4-MD5 are not among the first 64 ciphers in the client list (nobody
will ever need more than 640K^H^H^H^H 64 ciphers in their cipherlist).

-- 
	Viktor.