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.
I don't think that's quite what was being suggested. My understanding was that
by omitting the signature on some of the MXes, you could produce different
behavior depending on whether on not a client only uses secured MXes.
I don't think it's a useful feature, my understanding (now confirmed by you)
is that DNSSEC doesn't support that, and I also think, per my preceeding
messages, that if it were possible it would cause more problems than it solves.
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.
Well, that really depends on what you mean by "parallel". A field a client can
insert saying what server it was talking to, what protocol choices were made,
and so on and so forth, is fine. But the minute you try and link the
Transmitted: field to the corresponding Received: field the client hasn't even
seen yet, that's not a good idea. There's too much piddling around with headers
in practice to use such linkages.
Reusing basic Received: field syntax is also fine, and probably the right
approach if we are to define such a thing. But I again wonder if this belongs
in this proposal or would be better off in a separate document.
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.
Not to mention that the signature cannot be generated in advance and would have
to be computed during dequeue processing. In regards to signing at this point,
had DKIM's canonicalization/hashing mechanisms been designed differently and had
different signature algorithm choices been made, this might, and I emphasize
might, be technically feasible. But they weren't, so it isn't.
I'm also not wild about extending the usage of DKIM past the use cases it was
designed for, and this seems to me to be doing that.
I also have to question why signature coverage is needed in this case. The
entire point of this mechanism is to insure that the client is talking securely
to the right server. So the presumption is the message cannot have been
tampered with in transit. And that leaves the client. If the server trusts the
client, then it can trust the uppermost Transmitted: field, signed or not If it
doesn't, then having the untrusted client add an untrusted signature adds...
what exactly?
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.
Exactly.
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".
Ah, that's clever. Avoids the need for a new field. I like it.
(So regarding Ned's comemnt about the need for a general mechanism, I
think RFC 3464 is, happily, already sufficiently general.)
With the "dane;" MTA name type approach, agreed. That's absolutely where
it belongs.
Ned