On Fri 25/May/2012 19:15:36 +0200 Tony Finch wrote:
I have just submitted an I-D describing how to use DANE with SMTP. All
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.
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.
example, if a domain sets up a dummy backup MX that should work as a
sort of honeypot, it might want to deliberately omit to add security
features to its setup while still allowing secure mail delivery on
their main MX.
Here you're envisioning an application that DNSSEC was never intended to
support. New secondary applications are OK as long as they don't infere with
the primary application a service was intended to provide. But that's exactly
what this does.
Second, for XXX, I'd suggest updating RFC 5451 and extend it as
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.