On Tue, Jan 28, 2025 at 10:53 AM Michael Thomas <m...@mtcc.com> wrote:
> > So you're looking for a "No other work is considered to be within this > charter" statement? If not, I'm not clear what you're asking for and > request some text you'd like to see added or changed. > > I'm asking if that was actually the intention. > Yes, that's the intent. > But in your objectives if that was the intention, you could make it > explicit to say that "The scope of the working group's work will address > the following objectives..." or something like that, so the chairs can > refer back to the charter to not take on new work. > > That is, suppose somebody wrote a draft to upgrade cipher suites. In scope > or not? > Assuming I don't make this change, we would leave it to the chairs and ADs to interpret the charter and determine whether something else fits within it. If it were me, I would default "no" for anything not clearly in service to one of the stated objectives. If we're fine with that interpretation, I don't think we need to say more. If we're specifically worried about someone dabbling in crypto when they shouldn't be, we could explicitly call that out. I know that's a pet peeve sometimes. > > >> I will also note that the "back scatter" problem is mentioned, but is >> not in the objectives. That suits me if the objectives are the scope, >> but it makes it an orphan. > > > I think the third objective is the intended solution to the backscatter > problem, and one of the proponents should feel free to either correct me or > confirm. > > 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. 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. > Also about mutations: you should probably be more precise that it's > mutations to the signed canonical text of a particular signature. That is, > just adding a received: header doesn't need to be considered. > OK. > 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. -MSK
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
