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

From: Chris Newman <[email-masked]>
Date: Tue, 05 Nov 2013 17:01:54 -0800

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.

Page 6:
>   or all destinations, in which case mail delivery will be deferred
>   when "secure" TLSA records are absent.

*1* This should state whether the error is permanent or temporary
(deferred implies a temporary error but it'd be nice to make it
explicit). An SMTP enhanced status code should be defined and
registered for this error condition. The registry was introduced by
RFC 5248. Here's the IANA link:

http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml#smtp-enhanced-status-codes-3

I suggest a new X.7.X code would be appropriate for this case. A few
lines of text describing the meaning of the code in an IANA
Considerations section is all that's needed.

Page 9:

>   Note: CNAMEs are not legal in the exchange field of MX records, thus
>   MTAs are not obligated to perform MX exchange CNAME expansion.  If an
>   MTA does not perform CNAME expansion, there is potential risk, that
>   the MTA may fail to notice that it is one of the MX hosts for the
>   destination and that it must skip MX records with equal or worse
>   (numerically higher precedence).  If an MTA does allow CNAMEs to be
>   used in MX records, it SHOULD process them recursively as described
>   above to determine the most appropriate TLSA RRset base domain.

This document is a bit long. I suggest dropping all text after the
first sentence in this paragraph. I don't think it's worth the words
to describe how to accommodate misconfigured deployments.

>   with custom routes specified by the MTA administrator or when an MUA
>   connects to a submission server on port 587.  The SMTP client MUST

*2* I believe it's undesirable to attempt to deploy DANE TLSA for 
submission services (port 587 or de-facto port 465) as it may cause 
confusion and possibly harm to the MUA infrastructure more than it causes 
benefit. I'd prefer for submission clients to implement the same TLS 
certificate algorithm for all three of POP, IMAP and Submission. The 
current algorithm described in RFC 3501 (similar to RFC 6125) is what many 
implement.

A compromise position would be to link the DANE TLSA lookup with an 
attempted MX lookup. That is, if a submission client looks for MX records 
with the submission server's name (a practice that is uncommon), then it 
should also look for DANE TLSA. Otherwise traditional TLS verification 
should be used by submission clients.

The MUA infrastructure is much more fragile than the MTA infrastructure 
when it comes to security. And it's often subject to the whims and 
limitations of client-OS-provided SSL libraries; having two different ways 
to validate certificates at the client side is more
likely to break things than to improve them. For MTA relay, the opposite is 
true both due to the use of MX records and because traditional TLS server 
authentication is generally not used for relay.

Page 12:

>   anchor certificates in server trust chains.  SMTP client
>   implementations SHOULD support these TLSA RRs, unless, despite the
>   above warning, a non-trivial fraction of server operators fail to
>   publish certificate chains that include the required TA
>   certificate.

It sounds like you really want this to deploy (because it simplifies
the operator's job) but you're worried it won't due to operator CA
management errors. So how about adding a requirement for server
implementers so the management error is likely to be noticed by the
right people. Something like:

"SMTP servers implementing DANE TLSA SHOULD verify that the CA for a
 server certificate that will be provided by TLS is installed on the
 server and SHOULD log an error or disable TLS support if the required
 CA is missing."

Speaking with my server implementer hat on, I think I know how to
write that code, but I won't be able to justify the time to do so
unless it's at least a recommendation in a spec we claim to
implement.

>   or "1".  SMTP clients cannot be expected to be configured with a
                 ^
               relay
>...
>   public CAs, SMTP clients cannot (without relying on DNSSEC for secure
                    ^
                 relay

I disagree that this statement is true for submission clients.

>   SMTP client treatment of TLSA RRs with certificate usages "0" or "1"
        ^
      relay

>   MX:  If the TLSA base domain was obtained indirectly via an MX lookup
>      (it is the name of an MX exchange that may be securely CNAME
>      expanded), then the initial query name used in the MX lookup
>      SHOULD be accepted in the peer certificate.  The CNAME-expanded
>      initial query name SHOULD also be accepted if different from the
>      initial query name.

This text makes me quite uncomfortable and I think some discussion is 
merited. I'm not sure if all TLS stacks support certificate validation 
against more than one name. And having a single name is a common 
simplification in higher-level TLS APIs. I'd prefer an algorithm where only 
one name is valid. Common TLS practice has been that the name that was used 
prior to any DNS or remote lookup (regardless of record type) is the only 
valid name. This issue isn't a show stopper issue to me, but it may be a 
deployment barrier and I want as few of those as possible.

Page 14:
>   The client may even offer to use anonymous TLS ciphersuites and
>   servers SHOULD support these.  No security is gained by sending a

*3* This paragraph needs to be removed. Here are my reasons:

1. For clients, using a regular cipher suite means the client has the
option of pinning the server certificate and then it can at least
record in an audit log if it's talking to the same server as last time
(even if it continues sending if the certificate changes).

2. TLS stacks are complex and the more code they contain the more risk
there is of a vulnerability. As clients have the option of ignoring
server certificate validation (or doing 1), there's no functionality
gain by having anonymous cipher suites in the stack. But there is
increased security risk by having that code present. Some TLS stacks
are removing anonymous cipher suites (or never included them) for this
reason.

3. The TLS protocol has interoperability problems if the client hello
has too many cipher suites in it. So some TLS stacks are busily
discussing which cipher suites to trim out of the default client hello
so that they can get a good "moving window" of security technology
allowing backwards compatibility and upgrade to strong modern cipher
suites. Enabling the anonymous cipher suites would cause the moving
window to be smaller and thus deter upgrading to better cipher
suites.

As for the auditing benefit of anonymous cipher suites, I agree but I
believe there's a better way to address that issue that can be handled
in the document Keith & I are writing.

>3.  Opportunistic TLS for Submission

*2* For reasons stated above I believe this section should be removed.

Page 17:

>   Opportunistic SMTP TLS depends critically on DNSSEC for downgrade
>   resistance and secure resolution of the destination name.  If DNSSEC
>   is compromised, it is not possible to fall back on the public CA PKI
>   to prevent MITM attacks.  A successful breach of DNSSEC enables the
>   attacker to publish TLSA usage 3 certificate associations, and
>   thereby bypass any security benefit the legitimate domain owner might
>   hope to gain by publishing usage 0 or 1 TLSA RRs.  Given the lack of
>   public CA PKI support in existing MTA deployments, deprecating
>   certificate usages 0 and 1 in this specifications improves
>   interoperability without degrading security.

For SMTP relay, this is not a problem because there is near zero
deployment of RFC 6125 certificate verification in that
context. However, for SMTP submission, RFC 6125 verification is
deployed somewhat and works reasonably well (assuming one doesn't use
SRV records or does not mind a one-time MITM risk during account
setup). So the introduction of DANE TLSA to SMTP submission adds a
this new serious vulnerability that was not previously present. So
this is now another reason I oppose recommending DANE TLSA for
submission.

		- Chris

---

From: James Cloos <[email-masked]>
Date: Wed, 06 Nov 2013 08:33:14 -0500

>>>>> "CN" == Chris Newman <[email-masked]> writes:

CN> *2* I believe it's undesirable to attempt to deploy DANE TLSA for
CN> submission services (port 587 or de-facto port 465) 

TLSA SHOULD be checked for *all* TLS connections by clients.  We should
not have any RFCs which try to exempt certain ports, nor recommend
avoiding DANE for certain ports or services.

We want the TLS libraries to implement it (as gnutls has done) and for
applications to take advantage of DANE whenever they initiate TLS sockets.

The only real question is what to do when provided just an ip address.
Should the TLSA be checked in arpa., or should it look under the name
returned by a PTR lookup?

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: "Dickson, Brian" <[email-masked]>
Date: Wed, 6 Nov 2013 18:33:37 +0000

Sent from my iPhone

> returned by a PTR lookup?

I think, even if no TLSA records are found via those ways, that IF a cert is presented, a corresponding TLSA query should be made. That way, even if a random IP wants to pretend to be FOO, that FOO has the implicit opportunity to assert that the IP is not presenting the real cert for FOO.

Brian

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 7 Nov 2013 17:10:06 +0000

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.

---

From: Chris Newman <[email-masked]>
Date: Thu, 07 Nov 2013 17:32:26 -0800

Thanks for the thoughtful response!

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

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

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

>      when they obtain (or fail to obtain) appropriate TLSA records.

Point taken. I withdraw the suggestion.

>       to enable anon ciphersuites when not authenticating the server.

I have no problem with this. Those MTAs are free to make that choice.

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

>       SSLv2 vs. SSLv3 HELLO ambiguity.

Glad to hear that!

		- Chris

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 8 Nov 2013 02:39:02 +0000

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

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

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

> 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

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

> >      SSLv2 vs. SSLv3 HELLO ambiguity.

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.