Alessandro Vesely <vesely(_at_)tana(_dot_)it> wrote:
Thanks for your helpful review.
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.
The DNS deals with RRsets as a unit, not as individual records. Because of
this there is no way for a domain's MXs to have inconsistent security
states. See RFC 2181 section 5 for more.
For 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.
That is allowed, because there's no coupling between the MX targets, so
they can individially have TLSA and/or DNSSEC or not. There's a paragraph
about this in the security considerations section, which I am going to
expand because this area is fairly subtle.
Second, for XXX, I'd suggest updating RFC 5451 and extend it as
appropriate. A question is that the client-added header field should be
signed in order to be considered reliable.
I'll have a look at that. What I had in mind was a Transmitted: trace
header that parallels the Received: header, and some new "with protocol"
types (e.g. esmtpt) to assert that the client had done some extra
checking. But this would add a lot of bloat for one bit of information so
perhaps it should just be left in the logs. Dunno.
Regarding authenticity of the header, I could say that any DKIM
signature should be added after the Transmitted: header. But then you'd
have to generate different signatures for each transmission of a message
which is not currently the case.
But I'm not sure what a server can meaningfully do with knowledge of how
much checking an unauthenticated client claimed to perform. At the moment
I'm just thinking of this trace information existing for debugging
purposes and for deployment tracking and suchlike, so there's no need to
be particularly precious about it.
Unless I'm missing something, the only places where that info is going
to be relevant is if the server rejects the message, if positive DSN was
requested but the server doesn't support it, and if the sending fails
because some of the specified checks failed. In those cases, the client
can prepare a bounce where the authentication results are reported in
detail.
Hmm, yes, I should add something about DSNs. Thanks. I think it might be
sufficient to register a new MTA-name-type, perhaps "dane".
(So regarding Ned's comemnt about the need for a general mechanism, I
think RFC 3464 is, happily, already sufficiently general.)
Tony.
--
f.anthony.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
Bailey, Fair Isle, Faeroes: Easterly 4 or 5 in south Bailey, otherwise
variable 3 or 4. Slight or moderate. Occasional rain. Moderate or good.