-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have been carefully reading
https://datatracker.ietf.org/doc/draft-chuang-dkim2-sender-policy/01/ It contains a fair number of different proposals, and it is somewhat convoluted in places, so I will try and summarise here. I am not going to quibble about MUST/SHOULD or statements about local policy; the aim is to set out the basic issues. #1 the DMARC analysis of a message should use the RFC5322 From header field that existed when the first DKIM2-Signature was applied (ie wind back any changes and use the From that existed when i=1) However, receivers can use the current From: header field if they want to -- teasing out the interworking issues of setting out the choice in this way will be interesting I think. #2 a new auth= tag is added to DMARC records to specify what type of authentication is used for the domain. Values are dkim, dkim2, spf. I believe the intent is that if dkim2 is present then a message without a relevant DKIM2-Signature field should be considered unsigned (but the document doesn't say that anywhere I noticed) #3 the document does say <quote>Mail Receivers that evaluate DKIM2 for DMARC MUST only use validated DKIM2 signatures to protect any policy evaluation or enforcement from being spoofed</quote> it then (rather more helpfully) says that if there is valid chain of custody back to i=1 then this is an authentication pass -- and otherwise it is a "fail" (or neutral if there are no DKIM2-SIgnature header fields). It goes on to require a DKIM2-style match (such as we use for MAIL FROM) between the (d=) domain in the i=1 header field and the RFC5322 Mail From. #4 a new "unaligned" flag is proposed to say that there is no alignment between mf= and d= for this DKIM2-Signature field. This is explained in terms of DMARC alignment ... and to be honest I am just confused by this explanation (unless it is something SPF related because mf= has nothing much to do with DMARC). #5 MTA relays are _required_ to change the RFC5322 From header field to have a relaxed alignment with their d= domain apparently this will assist non-DKIM2 aware systems, but I don't see how they could know if the relay knows (somehow) that the destination is DKIM2 aware then they can set "unaligned" as they do this #6 If a DKIM2 system receives a DKIM1 signed message with a DMARC pass then it can set "unaligned" on its i=1 DKIM2-Signature header field to flag this. this isn't of course "trust me" because the DKIM1 signature could be checked by any recipient ... what it does not do of course is to provide any anti-replay guarantees ... as discussed in #4.1 -- where there is an assumption made that message recipients are always named in To: or cc: header fields (which is of course untrue) #7 An attempt is made to handle DKIM2 unaware relaying. Section #3.3 says <quote>Because the DMARC RFC9989 "auth=" tag can serve as a DKIM2 capabilities mechanism, a DKIM2 aware SMTP relay sender can check if the receiver supports DKIM2.<quote>. This is of course wrong since complex mail handling systems do not have well- defined matches between incoming and outgoing email domains (and a MX record can point to another organisation altogether) My own view remains that we simply update the spec to say that when a - From field is first placed into a message (ie it sits alongside an i=1 DKIM2-Signature) or when it is changed by an intermediary (there is a recipe that shows that it has been changed at a particular hop) then DKIM2 will insist that there is a relaxed match between the d= domain being used to sign at that hop and the domain in the RFC5322 From header field. This is really simple to understand, implement and check. It will require any changes to what people do at the moment day to day. Various DMARC equivalent properties flow from this -- but DMARC can be changed down the road if it still seems to be useful. I have heard the argument that this is putting a policy issue into a signing spec, but I would be surprised to hear people saying that have realistic use cases where this "policy" was not what they did anyway for any email that they were currently authenticating. I think the other proposals fall away -- EXCEPT that the auth=dkim2 flag is extremely useful to ensure attackers cannot strip headers and get old-style behaviour... Now if it is placed into a DMARC record then this has a cost (finding these records is a little complex). I am sanguine about suggesting a new record because it is inherently a DNS change for senders and it may or may not be simpler to have a new record or a new tag in an existing one. - -- richard @ highwayman . com "Nothing seems the same Still you never see the change from day to day And no-one notices the customs slip away" -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBaqnXKWHfC/FfW545EQLePQCfW+bFh8pKNVqzKLcNIE279+U6rngAnjAZ UDMVF3kzsohds/qUQOHtIYBn =L4Yi -----END PGP SIGNATURE----- _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
