On 1/28/25 2:31 PM, Murray S. Kucherawy wrote:
On Tue, Jan 28, 2025 at 10:53 AM Michael Thomas <[email protected]> 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.
Ok, that's good to hear.
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.
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"?
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.
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.
Mike
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
