On Tue, Sep 15, 2026 at 4:46 PM Richard Clayton <[email protected]> wrote:
> -----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. > As laid out in the draft, I think the RFC5322 From at i=1 originator ought to be the governing sender authenticated identifier, as that is presumably the author. Subsequent RFC5322 From identifiers work on behalf of the author. However that draft acknowledges the procedures given in draft-ietf-dkim-dkim2-spec which is to use the RFC5322 From from the most recent DKIM2 signature i=n, thus supporting both. > > #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) > Yes, that is an oversight. I propose adding language that states: Presence of expected authentication SHOULD be validated. Given the DMARC DNS policy fetched with the authenticated identifier, the sender specifies any implied default or explicit authentication defined with the "auth=" tag. The expected authentication has the following qualification due to forwarding: dkim: a DKIM signature MUST be present though it need not be passing. dkim2: DKIM2 signatures MUST be present and MUST have a valid chain of custody. spf: no stipulation because of forwarding If the expected authentication is missing, the mail receiver SHOULD apply the sender's enforcement policy. > > #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> > The intent is to state that any policy derived from a signature, that signature must be validated. A policy derived from a signature i=N, then that signature must be validated. It is not to require validation of all signatures to i=1. > > 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). > The purpose of the "unaligned" flag is to provide a pathway to allow relays to stop RFC5322 From rewriting, though that may take some time. In the near term, we will likely need to support RFC5322 From rewriting to support legacy mail receivers. In the long term, when everyone supports DKIM2, then this won't be necessary. The alternative is alignment for each DKIM2 signature at the SMTP transaction boundary with the associated RFC5322 From rewriting. > #5 MTA relays are _required_ to change the RFC5322 From header field to > have a relaxed alignment with their d= domain > Are you worried that I overspecified "relaxed" alignment in a place where that specification isn't needed? > > 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 > Agreed. > #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) > There's a description in the Section 4.1 <https://datatracker.ietf.org/doc/html/draft-chuang-dkim2-sender-policy-01#name-dkim2-interop-with-dkim> in the BCP section about providing evidence that a message entering DKIM2 from DKIM1 hasn't been replayed for interested parties, but doesn't rise to level of normative specifciation. It essentially puts the mf= and rt= addresess into the RFC5322 From and To/Cc header fields. An alternative is to drop that language in the BCP, and rely on the existing warning in section 4.1 that anyone introducing DKIM1 traffic into DKIM2 is responsible for preventing replay. If they don't they are readily identified. > #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) The difference between inbound and outbound is more under the covers. What's more important is having a well-known location to look up such domain level policies that DMARC affords both in terms of specification and caching infrastructure. > 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. > Which cost are you worried about? -Wei > > - -- > 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] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
