On 5/3/19 2:02 PM, Bill Cole wrote:
If the signer domain and the From header domain match, a valid DKIM signature that includes the From header is authentication of the From header to the limits of DNS trustworthiness and trust in the integrity of the domain's authority.
Which section of RFC 6376 supports this statement?I just re-read large chunks of RFC 6376 and see verbiage that states the opposite. All of which seem to me to specifically avoid drawing any conclusion about the authorship of a message within the context of DKIM. Further, such conclusions are left to other things making policy decisions based on DKIM results.
| § 3.11 - Relationship between SDID and AUID | | INFORMATIVE DISCUSSION: This document does not require the value | of the SDID or AUID to match an identifier in any other message | header field.DKIM does not require SDID or AUID to match any other header field. As such, DKIM itself can't be relied upon as authentication of other header fields.
| This requirement is, instead, an Assessor policy issue.Per § 2.7, the Identity Assessor "consumed DKIM's payload" which tells me that it is not part of DKIM. I believe that "Other DKIM (and non-DKIM) values can also be used by the Identity Assessor…." supports the fact that the Identity Assessor is external to DKIM.
| The purpose of such a linkage would be to authenticate the value in | that other header field. This, in turn, is the basis for applying a | trust assessment based on the identifier value. Sounds like the job of the Identity Assessor to me. | Trust is a broad and complex topic, and trust mechanisms are subject | to highly creative attacks. The real-world efficacy of any but the | most basic bindings between the SDID or AUID and other identities is | not well established, nor is its vulnerability to subversion by an | attacker.Sounds like the DKIM spec is specifically trying to avoid a tricky issue and instead sticking to the simpler verifiable facts of has the message been modified since it was signed.
| Hence, reliance on the use of such bindings should be strictly | limited. In particular, it is not at all clear to what extent a | typical end-user recipient can rely on any assurances that might be | made by successful use of the SDID or AUID.Sound to me like RFC 6376 is not even willing to loosely assert any relationship between the SDID / AUID / other headers.
To me, RFC 6376 goes out of it's way to avoid that conclusion and avoids asserting any authentication of the From: header.
This is authentication analogous to the authentication of the envelope sender provided by SPF.
I can't even agree to that.I agree that SPF authenticates that a server is authorized to send an email purporting to be from an address in a domain that it's authorized to send email on behalf of. But that does not extend to anything about the sending address, much less actual author of the message.
Email has an implicit trust that domains have a unitary executive, so we assume that a signer for a domain is not spoofable.
I concede that a server (SPF) / signer (DKIM) is authorized to send email on behalf of a domain.
I don't agree that the trust in the server extends into any statements about the authorship of a message.
Well, I know that the entity in control of DKIM signing for tnetconsulting.net was willing to claim responsibility for the message to which I am responding.Willingness to accept responsibility for a message does not directly translate to vouching for it's authorship.
If the entity in control of DKIM signing for tnetconsulting.net is not an authoritative judge of "authenticity" (whatever that means... )
The "whatever that means" is EXTREMELY germane in this context.
for mail claiming to be from gtay...@tnetconsulting.net at the signing point, there is no way for me to detect that.
You have no way to know what, if any, authentication was done by the signing server.
As such, I believe the only safe thing that can be done is to assume that no authentication was done.
If the entity in control of DKIM signing for tnetconsulting.net chooses to sign mail claiming to be from an address in some other domain, there is no discernible reason to deem that to be authentication,
I believe this should be the behavior for all DKIM signature verification.As outlined above, there is no guarantee that the SDID / AUID / From (et al.) headers correlate, much less actually authenticate.
RFC 6376 states the following in § 8.3. | A more secure architecture involves sending messages through an | outgoing MTA that can authenticate the submitter using existing | techniques (e.g., SMTP Authentication), Submitter ≠ Author | possibly validate the message itself (e.g., verify that the header is | legitimate and that the content passes a spam content check),"legitimate" is rather nebulous. Is it as simple as making sure that it is an email address? Any email address? Or does it mean that there is correlation check between the email address and the credentials used to authenticate?
Many of the MSAs that I've run across over the years don't do any form of correlation between SMTP AUTH credentials and the email address used. One notable exception that I'm aware of is that Gmail used to do so. I'm confident that there are more examples of both types of MSAs.
| and sign the message using a key appropriate for the submitter | address.I wonder how many signers actually use something other than the default value of i= and specify something more specific.
| Such an MTA can also apply controls on the volume of outgoing mail | each user is permitted to originate in order to further limit the | ability of malware to generate bulk email.I think I've seen this being done. However IMHO it's not directly related to DKIM.
although it is still (according to the RFC) a claim of responsibility for that mail by the entity in control of DKIM signing for tnetconsulting.net.
"claiming responsibility for" ≠ "authenticating"Many university IT departments claim responsibility for what the university's staff and students do while decidedly NOT authenticating anyone. Think NATed internet connections.
So as Dave said: DKIM_VALID_AU has authentication value where DKIM_VALID alone has none unless you have some reason to trust the signer.
I still don't buy that as part of the DKIM specification.I will concede if SpamAssassin is functioning as the Identity Assessor, which as previously stated is decidedly outside of DKIM as specified by RFC 6376.
DMARC is not a signature. It is a statement of policy recommendations for how to assess and handle messages which purport to be from a domain but either fail SPF checking or DKIM validation *and alignment with From*ARC is a totally different thing, authenticating chain-of-custody.
Agreed on both accounts. -- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
