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

[Chris Newman <[e-mail]>]

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