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
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
