On Tue, Jan 28, 2025 at 2:56 PM Michael Thomas <m...@mtcc.com> wrote:
> That wasn't obvious to me, you might add some text that links the two. And >> "annotations in transit"... annotations of what? Also "intended"? What >> might be considered "unintended"? >> > The example I gave elsewhere is what I understand: If you're holding a > message and decide its next hop is X, you would include that little tidbit > in the new signature somehow. That way at delivery time you end up with a > verifiable record of the intended path, and if there's any indication that > something off that path handled the message, you have reason to be > suspicious. > > Ie, analogous to that new tag in ARC that linked the signature to an A-R > (iirc)? But my point was I didn't understand what you meant so either I'm > dumb or the text is not clear. I asked on another post whether it actually > involved DKIM/signatures or not and didn't get a very clear answer. So > you're saying "yes it does"? > The answer is open; generally, we're saying "consider using a new tag for this, but it's fine if you have to go to a fully new external mechanism". > > But I don't want to be that technically specific in the charter. We want > some solution to the backscatter problem, and this is the one currently on > the table. Let's specify it later. > > Well, you might just say that bullet three is in reference to the back > scatter problem, because it confused me. > Will do. > > One last thing: the charter seems like it's dancing around with whether to >> just upgrade DKIM or do something new. DKIM explicitly allows tag upgrades >> by telling evaluators they MUST ignore unknown tags. I think we should make >> explicit that adding a new tag is not a reason to create something new. >> That is, adding a new tag to a DKIM signature block is not "disturbing" the >> existing ecosystem. >> > That takes advantage of the existing extension mechanism in DKIM. We > already say "Pursuit of incremental enhancements to DKIM and/or novel > applications of DKIM are preferred, but not required." I think we need to > give this group the latitude to consider using new tags, but also accept > that that might not be enough to meet the full set of goals that have been > stated. It might be good to include in an appendix the reason the simple > new tag approach was considered and discarded; that would head off > challenges later during IETF-wide evaluations. > > What I hope to proscribe is some change to DKIM itself that renders the > deployed base broken, or some reason that when using $NEW_THING, you can > not simultaneously use STD 76. We should consider that unacceptable. We > probably don't want any flag days either. > > Yes, definitely. That would be extremely bad. But as far I can tell, those > three bullets can either be grafted onto DKIM or live as new headers (in > particular the mutations bullet) which doesn't involve changes to DKIM per > se. > The charter suggests that such an approach should be considered, but doesn't constrain the WG to only that possibility. -MSK
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
