Lots of fair points for discussion in this. Please keep in mind that the people working on this have been working on it for a bit, and it becomes easy to unintentionally treat details as obvious or not worth mentioning after repeated iterations. I don't think any omissions are being made intentionally, and calling them out will help us get the document into better shape.
On Wed, Mar 5, 2025, 6:43 p.m. Michael Thomas <m...@mtcc.com> wrote: > > Section 1: > > 1. verifying the path that messages have taken to get to it, > including by being able to reverse modifications or by asserting > that it trusts the previous hop unconditionally. > > First off, "unconditionally" seems like a very strong word especially wrt > "trust". The problem is that I'm not sure what it has to do with anything. > An intermediary can already resign a message, and receivers can make of > that what they will. > That word might be a bit strong. I think the intent is to convey that trust in intermediaries is required when the intermediary makes changes but can't/won't tell you what they were in a verifiable way. But if the intermediary does tell you what they did via the modification algebra, later systems can verify that the message received by that intermediary is what the intermediary claims to have received. > > 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. > > 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. 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. > There is no way to add these properties to existing DKIM1 in a way > which is both backwards and forwards compatible > > This is debatable to say the least. As stated it just a bald assertion. > Agreed. I expect this will be a topic of fierce debate as the protocol takes shape. And that's ok. > 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. 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. 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. 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. 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. 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. > > 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. > DKIM2 headers will always have timestamps so that "old" signatures > have no value. > > There already is an x= option with DKIM, so I'm not sure what's different > here. > > The difference is that it becomes mandatory with DKIM2. Admittedly not a huge difference. > A possibility to be investigated during testing is a "singleton" flag > to allow senders to specify that this is a message for a single > recipient (e.g. for authentication codes for billing transactions) > and should not be expanded by mailing lists. > > Not sure what this has to do with DKIM. Assuming it's useful at all, it > could be its own header which could be DKIM signed as usual. > These are both fair points. I don't think we know whether this will be useful or not yet, or whether there's a transport mechanism other than tags in a new header that would give us the desired properties. 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. Reputation itself may be out of scope, but I think it's reasonable to mention that the information conveyed through the handling chain may be beneficial for reputation systems. > 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. 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. > TL;DR there are a lot of assertions here that lack any justification or > show causality (re: replays). There also seems to be the high likelihood > that various completely legitimate uses of email would be a casualty of > this, and the (unintended?) consequences have not been enumerated or > considered. Finally, even at face value I do not see what would preclude > extending DKIM itself. > One thing that would potentially help here is worked out examples of how we think DKIM2 would alter various types of mail flows. The ones you mentioned specifically should be perfectly fine in a fully DKIM2-enabled ecosystem, and we'll need to carefully consider the interop story for the realistic world in which adoption is not 100%. > Mike > > > > > > > > > _______________________________________________ > Ietf-dkim mailing list -- ietf-dkim@ietf.org > To unsubscribe send an email to ietf-dkim-le...@ietf.org >
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
