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"?
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.
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.
[*] My short-sightedness may well be caused by my ignorance of DANE.