On Sat 26/May/2012 16:03:11 +0200 ned+ietf-smtp wrote:
I'm not into DANE or DNSSEC, but AIUI there's some over-constraining
in Section 3. The spec requires that the whole list of MXes is
secure, while it could be enough that the selected record is.
That's simply not true. The security of the entire set is essential, since
without you have no way of knowing if additional records of equal or lower
priority were present. As such, failure to secure the entire set opens the
door
to redirection and/or service denial attacks.
Even if the attack succeeded in causing a devious path, the sender
would still have transmitted the message to a valid, secure host.
Isn't that enough for tagging that single transmission "secure"?
Secure in the sense that the message cannot be tampered with or observed, yes,
but there's more to security than that. An unauthorized redirection might cause
a significant increase in message latency or might even allow the message to be
blocked completely. (Paths to different MXes often have very different
characteristics. In fact that's one of the main reasons for using MX records.)
Furthermore, I don't believe DNSSEC can actually be used this way. One of
the
design goals of DNSSEC is to minimize or eliminate the need for on-line
signing, which is both computatonally expensive as well as requiring that
the
DNS server have ongoing access to private keys. As such, it's my
understanding
(I'm only superficially familar with DNSSEC) that records are signed in
groups.
I just trust your word on this.
You probably shouldn't. My understanding of DNSSEC is pretty superficial.
Second, for XXX, I'd suggest updating RFC 5451 and extend it as
appropriate.
RFC 5451 is about communicating *authentication* results. This use of DANE
is
about making mail transport more robust. These are very different things and
mixing them is inappropriate.
The only difference I see[*] is that the client authenticates the
server rather than the opposite way around. Indeed, several
considerations in RFC 5451, in articular Section 7.1, assume that the
authentication server is on the server side of the SMTP transmission.
This shouldn't strike down the field format, though.
This is about securing the transmission path. Authentication is only incidental
to that. And in any case, the only identity that's "authenticated" here is that
of the receiving server, and that's supposed to end up in the Received: field
the server adds anyway.
I'm afraid I really don't see the point.
Ned