On 2/3/2025 8:58 PM, Murray S. Kucherawy wrote:
On Sat, Feb 1, 2025 at 10:00 AM Dave Crocker <d...@dcrocker.net> wrote:
As such, an honest and pragmatic charter needs to cite that draft
and needs to explicitly encourage consideration of alternatives.
I think I'm fine with adding something like this, though I would hope
everyone realizes that it's expected in open standards work and
shouldn't be necessary.
Including the citation, with low-reliance usage language, like, "as
input to discussion" is quite common. Again, it aids readers who are not
already familiar with the context of the working group.
As for your hope:
"... you might also note that the X people are probably not going to
spend many cycles to develop and test a DKIMbis since they have already
concluded it's not going to be capable of solving the problems they
consider to be important to them "
demonstrates a stance rather far from that hope, as did the other
appeals to authority. Also there is the lack of any serious engagement
in constructive discussion by the few folk active here, who were part of
the group of X people.
I'm pressing this point because it is common for IETF leads to respond
to these sorts of problems with this sort of broad, cautionary note to
the mailing list, and for it to have only a temporary effect, at best.
An Internet message (email) may, from creation to final delivery,
pass through multiple intermediaries, some of which simply handle
and route the message, others effecting an interim delivery and
re-injection into the ecosystem. There are complexities with this
handling model, such as evaluation, filtering, intentional
mutation, and even malicious activities.
Again, the term intermediaries does not have a clear, consistent,
widely-held meaning. It could reasonably mean MTAs. It could
reasonably mean mailing lists. Because it variously does.
There is no way to know what is meant here. Especially for a
potentially wide-spread audience, including folk with little email
technology background, but who need to understand the goals of
this working group. A charter needs to be understandable to such
folk.
...
But since we keep coming back to this paragraph, I'm starting to think
we could just drop it or cut nearly all of it. I don't think we need
to spend a ton of energy expounding precisely on the complexities of
email to lay the groundwork for this charter. "The email ecosystem is
venerable and complex" might be all we need to say.
Do you have an alternative suggestion?
Hmmm. On re-reading now, I see a simple change that will suffice, and
don't understand why it didn't occur to me before. My concern was only
with the word intermediary, and not with the rest of the paragraph.
To belabor my continuing point of concern about terminology: You send
me a note addressed to me. You send another note to this list and it
gets to me. These are profoundly different acts of communication. And
both the author and the recipient know it. Any technical discussion that
misses or denies that difference is going to make simplistic choices
likely to produce collateral problems.
But to suggest the specific fix here: handling agent, in place of
intermediary. Handling agent is generic and not a term of art or
otherwise in common use. I believe that it covers all of the relevant
architectural components, and it is used later in the draft charter.
There are contemporary issues, which were not concerns at the
time of STD 76 <https://datatracker.ietf.org/doc/std76/> or
earlier standards, that the community now seeks to address,
including the following:
*
There is a desire to maintain validation of a message's
signing identifier across common transit and forwarding
modifications. When a message goes through a re-posting, such
as through a mailing list, the validation signature typically
does not survive and cannot be recovered. Fixing this would
permit a more robust evaluation of the message.
'Message's signing identifier" has meaning only to experts and has
not been introduced or explained here.
There must be some reasonable boundary regarding how far into
definitions the charter has to go. It's enough, I think, that we
reference STD 76 where all of the background can be found.
Yeah. Sorry. Missed the linkage there. but, ummm, well, looking there
I am reminded that the term it uses is "signing identity". My discomfort
with the latter word here notwithstanding, I suggest using exactly the
term from that spec. sigh. sorry. mumble...
So, perhaps:
DKIM attaches a domain name to a message, by using a
cryptographic signature. The signature survives simple
relaying but does not survive transit through some
{intermediaries?}. There is a desire to retain signature
validity across a wider range of common transit, including
where modifications are made during forwarding, such as by
mailing lists.
Sure, but this drops the "some responsibility" language you had
provided previously. Are we OK with that?
The paragraph is about signature survival, and not signature use. So, yes.
The working group will strongly prefer output that, when
deployed, does not disturb the deployed ecosystem. It may,
however, through the normal course of evolution, replace
technologies such as DKIM, DMARC, and ARC.
The issue is less about disturbing the deployed ecosystem and more
with seeking incremental improvement, where replacement is a last
resort. The difference between these two is extremely important.
Especially given the demonstrated positions of the primary
advocates of this work.
How about this?
"The working group will prefer a result that is incremental to the
deployed ecosystem. It may, however, determine that a technology that
supersedes existing technologies such as DKIM, DMARC, and ARC, is a
superior solution. In either case, the working group will be expected
to document support for its decisions."
wfm.
Thanks.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
