These are requests for clarification for draft-clayton-dkim2-spec-04 <https://datatracker.ietf.org/doc/html/draft-clayton-dkim2-spec-04>.
There are three major areas that potentially need more specification as they call into question some of the replay protections that motivated this effort. It is also possible that I haven't kept track of all developments on this mailing list so I would be happy to be corrected and that my concerns are unfounded. First, one of the key features to prevent replay in a precise way is the "mf=" and "rt=" comparison, however the current specification lacks comparison of the local-part as far as I can tell. Section 10.2 calls for "Verifier SHOULD check that the rt= and mf= values in the most recent DKIM2-Signature header field are consistent with the MAIL FROM and RCPT TO". I interpret this to mean consistency of tag-values to the SMTP transport values but that doesn't say anything about comparing "mf=" and "rt=" values. Section 9.2. does mention comparison as part of the Signer actions. There it calls for "The match algorithm only considers the domain part of the rt= and mf= values, that is the local part is ignored". Section 10 introduction calls for "actions taken by a Verifier. In essence this will involve repeating all the actions taken by a Signer" so presumably this is the "mf=" and "rt=" comparison check. As a consequence, because the local-part is not checked, it leaves the possibility of replay to victims within the receiving domain, and only provides protection across different domains. To me this is a large omission because providing replay protection to users within the domain is essential if we are going to do this large effort of adopting a new standard. Instead I would expect to see a Receiver action to do an exact string comparison of the RCPT TO address against the "rt=" value with some allowances for EAI. Because of this omission, I don't see language in Section 6 that defines the local-part where I would expect it to be in the same form as used in the SMTP transport. Second, the verifier specification calls for checking the most recent DKIM2-Signature but does not describe validating the remaining of the DKIM2-Signatures or Message-Instances. This is called out in Section 10.2. title 'Check Most Recent Signature and Hashes for the Message' and the first sentence "A Verifier SHOULD check the validity of the most recently applied (highest numbered i= value) DKIM2-Signature and the associated (v=) Message-Instance before accepting an email". As far as I can tell, the remainder of the Section 10 "Verifier Actions" does not call for examining the rest of the chain. In particular there isn't a procedure to apply the recipes in the Message-Instance Header Fields to obtain the header and body hashes and validate the signatures for i=value-1, and successively the remaining i values. A lot of the value in DKIM2 authentication is locked up in how to do that processing and I would suggest that a future version of this draft covers that. Third, there should be an alignment check between the "mf=" and "rt=" domains and the DKIM2-Signature d= domains. Ideally the domain names are matched with some allowance subdomains i.e. "relaxed" matching. For a given DKIM2-Signature at some "i=value", the "mf=" should match the "d=" at that value, and the "rt=" should match the "d=" for "value+1" if that DKIM2-Signature is present. Alternatively, if this alignment check is considered to be too strict, then the DKIM2 protocol should call for the sending domains to publish a DNS policy that describes who is allowed to DKIM2 sign on their behalf. Receiver can then verify that the signer is expected. Without this alignment system, what is to prevent a spammer from taking a message and adding their own spammer controlled signature? The specification in Section 9.2 calls for "mf= on the outgoing message would not match with the rt= value then the Signer MUST generate an extra DKIM2-Signature field that causes values to match", but a spammer can generate a signature for this. For example, and noting that d= alignment is not required as far as I can tell: The original message was DKIM2 signed: DKIM2-Signature i=1; d=orig.example.com; [email protected]; rt= [email protected] A spammer acquires this message, and then re-signs it with a DKIM2 i=2 signature: DKIM2-Signature i=1; d=orig.example.com; [email protected]; rt= [email protected] DKIM2-Signature i=2; d=spammer.com; [email protected]; rt= [email protected] Thanks in advance for your consideration and comments. -Wei
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
