On Thu, Mar 6, 2025, 5:56 p.m. Michael Thomas <m...@mtcc.com> wrote:
> > On 3/5/25 5:52 PM, Allen Robinson wrote: > > >> 2. declaring (under protection of its own signature) where the >> message is being sent to next. >> >> >> Assuming this means copying the rcpt-to in the 822 message, that doesn't >> require any modification to DKIM itself. There is no necessity that it be >> part of the signature block since it could be an independent header, though >> it may be more convenient to do so, but that would just require an upgrade >> to DKIM, not a replacement. >> > I do think it's worth considering if there are alternative transport > mechanisms for the information DKIM2 wants to convey along a message's path > to its final destination. The people working on this largely don't believe > DKIM+extra headers is workable, but declaring that it's impossible (or > possible) before we even know what we're trying to transport seems a touch > premature. > > Well, this draft is definitely taking a position on that. The authors are > more than welcome to not take a stand, imo. > > > >> 3. promising that it will pass control messages (including bounces, >> abuse reports and delivery notifications) back to the previous >> hop for a reasonable time. >> >> Again, I'm not sure what this has to do with DKIM. And which "previous" >> hop? The previous hop as evidenced by received headers, or previous hop as >> evidenced by signatures? What is the purpose of this? And what does >> "reasonable time" mean? >> > Previous hop here refers to the previous DKIM2 signer. Every system is > expected to add a DKIM2 signature declaring that it handled the message. > > Why is this better than the current practice of sending it to whatever is > in the 821.From address? > It's actually expected to be exactly that. The chain's most recent header will have a mf= tag containing the 821.From. > > What does it have to do with DKIM? Mostly having a better-authenticated > place to send the notifications, which as you mention is already sent. > > Why does authenticated or not matter? Again, none of this is obvious to > me. Maybe it's just me, but maybe it isn't. > Backscatter is why this matters. > > By only allowing precisely one destination address per DKIM2-signed >> email, and encoding that address in the signature, messages will be >> unable to be replayed to any other destination. >> >> There is no explanation of cause and effect here. Is a receiver supposed >> to say a signature is invalid if the rcpt-to in the SMTP conversation is >> different than the rcpt-to in the signature? If so you've now broken the >> forwarding ability of DKIM and a completely legitimate use of email in >> general. >> > Yes, the expectation is that the RCPT TO matches what's in the most recent > header. This doesn't break forwarding as the forwarder would add a DKIM2 > signature to indicate that they did the forwarding, and that would contain > the new recipient address. > > It invalidates the originating signature though (actually all of the > previous with different rcpt-to). This seems at odds "mutation" goal too. > The signatures form a chain. The recipient address of one signature is expected to be aligned with the source address in the next header in the chain. A verifier would only be looking for the current 821.From to be equal to the most recent (highest instance number) signature header in the message. > > As for effect, there's little value in sending the same message a billion > times to one address. There is significant value in sending the same > message to a billion different addresses, and that's why replay is a > problem. > > Here is my thinking. What's wrong with it? I am a spammer using an ESP: > > 1. I craft some spam and I test it across a range of anti-spam filters (or > just gmail's) and voila, I find one that will pass their filters > > 2. I then take that message and send it to my list of recipients. I can > use rcpt-to bunching or not. If I do a single rcpt-to per, I will have to > resign my spam for each recipient, but that doesn't seem like an onerous > requirement. I might grumble about it, but in the end of the day I -- the > spammer -- will do what is necessary. > > The essence is that the message content got past the filters. Whether it > has to be done one-by-one or in batches seems like an operational issue. > > In any case, I think a larger problem is that to my knowledge the draft > doesn't even define the scenarios in which "replay" is a problem, so if > that's not the right scenario, that's on the draft because it doesn't lay > the problematic scenarios out. > You are close. The attack methodology was for a malicious user uses the ESP's system to generate a message that's authenticated against the ESP's domain, and then resend that unmodified at scale to other recipients. A spammer sending authenticated mail from a domain they control is not DKIM replay, even if the content of the message was originally generated by an ESP. See also https://datatracker.ietf.org/doc/html/rfc6376#section-8.6 > > 2.2. A chain of aligned DKIM2 signatures over SMTP from/to pairs >> If the recipient wishes to forward the message on to another address, >> it must apply its own DKIM2 header, signed by a key which is aligned >> to the domain of the recipient address in the previous DKIM2 header, >> and with a bounce address which is in the same domain. >> >> >> I don't know what "aligned" means. And DKIM keys have nothing to do with >> the recipient. If that is a new requirement, it would be good to know why. >> If it's just an operational issue that can already be done with DKIM now, >> it would be good to know that too. >> > Not well-defined here, but for early discussions think of it as > conceptually similar to DMARC's identifier alignment. > > Align what with what? > Hopefully examples will make this more clear. > > > The description is a bit wordy. A concrete example is if the first DKIM2 > header says the recipient is someth...@foo.com, the second DKIM2 header > should be signed by something aligned with foo.com, and the MAIL FROM tag > in that header should have alignment with foo.com as well. > > I've tried several times and am not getting it. What if the intermediary > is not the originating domain? It won't have keys to sign for foo.com. > And it certainly won't have keys for the rcpt-to domain. > > That and it makes me nervous about intermediaries that change the > mail-from -- like mailing lists to they get the bounces not the originator. > I think you're envisioning there being one signature. Typing this out on mobile is going to be prone to errors, and also doing this from memory without the tag name table in front of me, but I hope it helps. We really need to produce fully worked out examples. Originator signs first Dkim2-sig: i=1 mf=m...@example.com rt=l...@listscorp.com d=example.com Listcorp.com sees that 821.From and 821.To are equal to mf= and rt= respectively, and that d= is aligned (like DMARC) to the domain of mf=. Also d= must align with 822.From for the initial hop. Listcorp.com decides to send a copy to another address, and prepends another signature Dkim2-sig: i=2 mf=list-sen...@listcorp.com rt=al...@hideme.com d= listcorp.com Hideme.com sees that the 821.From/To match the latest signature, that the d= aligns with the mf=, and that the latest header's mf= is aligned with the previous header's rt=. Hideme.com can validate that the previous signature still passes, because the message wasn't modified along the way. Modification algebra aims to make this possible even if modification was performed by listcorp.com Hideme.com is an aliasing service, and forwards the message along to a mailbox provider. They add their own signature in the same way as listcorp.com did. > > > The end result is, like ARC, a chain of domains which have handled >> the message; however unlike ARC, this chain MUST be fully linked in >> both directions, with every sending address aligning to the recipient >> address of the previous DKIM2 header. >> >> Why is this useful? I don't know what "fully linked" means either. And >> what happens if it passes through a domain that doesn't resign it? It's >> really hard to understand what the point of this is. >> > Fully linked here means that every signature header's from address has > some relationship to the previous signature's recipient. > > I'm sorry, I don't understand this at all. Which from address? And what > exactly is the utility? What problem is being solved? > > This is yet another example that makes it plain that the authors have some > model in mind, but the draft doesn't state it so the rest of us are left in > the dark. > >From address is the value in the signature's mf= tag. Recipient is the value in the signature's rt= tag. > > > Interop with non-supporting systems is certainly an area that will need > further thought. Particularly because it will look very similar to > malicious alteration or replay. > > 2.4. A way to describe changes >> >> Since this is a "motivation" draft, it would be to now what... motivates >> this. Also it seems to conflict with the requirement that mismatched >> rcpt-to signatures should be ignore/invalid/whatever. That is, I could >> reconstruct the canonical text for the original signature, but if the >> rcpt-to is different from the signature it ought to be rejected on those >> ground. Or something. >> > Being able to undo changes allows verification of every signature along > the chain, if one were so inclined. The most interesting is probably > getting back to the originator's content but there could be uses for > verifying intermediary signatures as well. > > But the originating signature would still fail on the rcpt-to grounds, > right? That is, a mailing's subscribers addresses is not going to match the > rcpt-to of the original signature as an example. > No, there is no expectation that all signatures have a recipient address equal to the current 821.To. Only the most recent (highest i=) signature is expected to have this property. Hopefully the example above clarifies this. > > Again, clarity of what happens when the rcpt-to in the 821 conversation > doesn't match the rcpt-to in 822 message is needed. I don't think it > mentions what that means. > It will mean that the message is not considered authenticated by DKIM2. What is done with a message that's not DKIM2-authenticated will likely need to be driven by local policy and not driven by the protocol, similar to other authentication mechanisms. > > >> 2.5. Simplification of signed header list >> >> What is the point of this? What problem does it solve? >> > > I think this is an opportunistic simplification based on operational > experience, and not a hard requirement for DKIM2 to work. One could easily > envision a version of DKIM2 with exactly DKIM's handling of the signed > header list. > > As Dave alluded to in his review, there's considerable evidence that we > don't know of one particular set of headers that should be signed. And the > way it is in DKIM is a feature, not a bug in any case. It allows new (or > old) headers to be signed without changing the protocol. > > I would just drop this completely, especially it's not part of the charter. > The proposal is a bit of a hybrid. There's a fixed set of headers that must be signed first, and the h= tag that allows for signing of additional headers if the signer decides that's an appropriate thing to do. I agree 100% that a fixed set of headers with no capability for extension by the signer would be fatally flawed. > If the >> email has been duplicated then recipients can assign a reputation to >> the entity that did the duplication (along with the expected number >> of duplicates that will arrive from that entity) and assess duplicate >> signatures on that basis. >> >> I'm pretty sure you can do this already. But reputation is definitely out >> of scope. >> > There are heuristics for detecting replay. One of DKIM2's effects is that > the detection becomes easier because you have a verifiable chain of custody > for the message. > > That's what I'm not getting. How? > I've tried to clarify this above. > 4.2. Reducing crypto-calculations >> >> The irony here is palpable. The easiest way to "reduce >> crypto-calculations" is to not invent a new protocol, but upgrade the >> current one. And of course there is no requirement the receiver verify any >> signatures at let alone all of them, so I don't know what the point of that >> is. >> > I'm not sure how your proposed extension of DKIM approach would result in > less crypto than what is proposed in DKIM2, as even if it were DKIM+extra > headers the protocol would still require signing at every intermediary > system. > > Well, if it's a DKIM upgrade rather than a new signature it will be one > less assuming the DKIM signature is still required which I can envision any > world in which wasn't. > Ok, I get it now. > > Having a goal of minimizing the computational, network, and storage cost > of the new thing seems like a good idea. Maybe minimize rather than reduce > would be better though? If we happen to reduce cost, great, but if we fail > to reduce that's probably also fine as long as we decided the extra cost > provides value. > > Well, Google doesn't seem to be too worried about it with two ARC > signatures and some weird X-Google-DKIM-Signature. Frankly I'd just drop > this line of thinking: any performance gains are going to be on the > margins. > Google is generating a number of signatures that they believe are providing value. I don't think there are concerns about the cost of signing when value is derived from that, and aiming for not being wasteful by doing useless work doesn't feel like a pointless goal. But yes, maybe this doesn't belong in the motivation draft. > > Mike >
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
