On 11 Dec 2024, at 22:59, Murray S. Kucherawy wrote:
I've uploaded the charter text at the top of this thread to the
tracker
(not the one from 11/27 yet). I wanted to do another round trip on
some of
Dave's points.
I am not concerned with milestones yet. The text is far more
important.
On Wed, Nov 27, 2024 at 4:15 PM Dave Crocker <d...@dcrocker.net>
wrote:
Summary:
- As provided, this is an extremely broad and extremely vague
statement of work. It continues to sound far more appropriate for
the IRTF than the IETF, especially absent a concete draft
specification to take as input. (It's not as if the IETF hasn't
accepted charters like this. But it /is/ as if such working
groups have typically not fared well. Stated more baldly, "let's
charter a group and then figure out what we are going to do" has a
bad history in the IETF.)
Bron (or anyone involved), do we have any initial documents to propose
formally in the charter?
Murray, are you looking for existing documents to be listed in the
charter that might be proposed for adoption, or do you want a more
detailed description of what documents that will fulfill the charter
will contain?
At base, I disagree with Dave that this is anything like IRTF work (in
that the IRTF, as least as constituted today, is doing things that fall
into academic research, not pre-standards work) or that work brought to
the IETF needs to be somehow more concrete than the work proposed here.
The motivation draft is far less of a "broad" and "vague" base document
than initially provided for much successful work proposed in the IETF,
and this work is building on already existing DKIM mechanisms, so I
don't understand Dave's evaluation of this proposal. That aside, the
technical folks who are proposing the work are a group of serious
implementers who have already successfully implemented and deployed DKIM
(among other email infrastructure) and are bringing this work with that
implementation and deployment background, so I think there is a hight
likelihood for success.
- The draft seems to include a target of 'trust relationships'
which is an open research topic that DKIM only indirectly relates
to, except for trusting a signature.
DKIM benefits from trust relationships, as does any other
authentication protocol, and is of limited use without them, but pays
very little attention to them in text because they are the purview of
an implementation's "special sauce". If there's a clear intent to
develop an interoperable notion of trust relationships (i.e.,
reputation), we should say so explicitly, otherwise I suggest that we
should avoid the topic or, at a minimum, leave it to a
post-rechartering topic.
Agree that this should be left for post-chartering, if tackled at all.
- IETF Internet Mail handling really only covers a single
posting/delivery sequence. It touches on more elaborate sequences,
but only piecemeal. And draft charter does not really note or deal
with this difference in scope. So the proffered 'holistic' effort
is a very considerable increase in scope from something labeled
DKIMbis or DKIM2.
I concur, though I don't believe this is a showstopper, is it? Maybe
we just need to be more explicit that the scope here is to try to
carry authentication information from injection through delivery and
every intermediary in between.
I agree it's not a showstopper. 5322's discussion of "Resent-*" fields
(see particularly the "Note:" on forwarding in
https://www.rfc-editor.org/rfc/rfc5322.html#section-3.6.6) goes beyond
single posting/delivery, and I think this work can do the same. I do of
course think that mailing lists, particularly those that rewrite the
contents of messages, are the elephant in the room for all of this work,
but I think the folks proposing this work have a handle on how much work
they've bitten off. (And I'll give Murray a hard time for saying that
this is about intermediaries between injection and delivery; as Dave
below, it is a series of injections and deliveries.)
DKIM2 Draft Charter
---
**[Background](https://notes.ietf.org/#Background)**
Emails often flow indirectly through multiple systems, undergoing
redirection, expansion into multiple copies via aliases and mailing
lists, as well as rewriting and filtering before eventually arriving
at a mailbox or being processed by a receiving software agent.
The opening sentence sets a stage that matches many end-user
experience views of email, but misses the basic technical distinction
that is the essence of the enhancement being sought. **As described
in that sentence, email is delivered more than once, before it is
'finally' delivered.**
That sentence does not use the word "delivery" at all and therefore does
not imply that delivery (as understood in email architecture terms)
happens more than once, or that it is "finally" delivered. If the
objection is that the phrase "eventually arriving at a mailbox" is
incorrect because each act of redirection, expansion through alias or
MLs, rewriting, and filtering is itself an act of "arriving at a
mailbox", I can see improving that phrase to, "before arriving at a
particular mailbox or processed by some receiving software agent".
Overall, given that charters are information for the entire IETF (and
beyond) to understand the work that is being done (in addition to
defining what the WG may and may not work on), I think leaving the
opening in terms of the functional (what Dave calls "end-user
experience) view and get more precise if it is called for later in the
charter.
So instead, perhaps:
It is common for an email to go through multiple posting/delivery
sequences, before eventually arriving at a 'final' mailbox or being
processed by a 'final' receiving software agent. Examples of such
'indirect' flow include redirection through an alis, expansion into
multiple copies via an alias or a mailing list, as well as rewriting
and filtering before eventually arriving at a mailbox or being
processed by a receiving software agent.
Would like to hear other opinions of this.
I think this proposal over-complicates the introduction, leaving the
reader guessing what important distinction is being made by putting
'final' and 'indirect' in scare quotes. I'd rather see the original
opening with the clarification I gave above.
I left 'rewriting' in but actually don't know what it refers to, nor
why 'filtering' is relevant to DKIM signature survival.
(By the way, I thought that posting from an ESP was also classed as
an indirect flow. Is this not correct?)
I presume "filtering" includes any sort of stripping of material an
intermediary or edge MTA might consider to be worth stripping for
whatever reason (e.g., malformed header fields) but I agree that an
example might be helpful to clarify.
I imagine "rewriting" is there for any of a number of reasons. Very
early on in my email career I used to see things like m...@example.com
used externally but it was rewritten (unnecessarily, it turns out) to
m...@host.example.com prior to delivery when the main ingress server
figured out which host was mine. There are probably more apt modern
examples.
Yep. "Rewriting" I take to be the aforementioned mailing list elephant.
"Filtering" is (AFAICT) just another example of indirect flow where a
message leaves and is reintroduced into the transport system.
And yes, I think ESPs count as an indirect flow.
- DKIM provides a way to detect that the content of a message was not
altered between the signing domain and its eventual destination.
This sounds correct but can be misleading, given the 'eventual'.
...between the signer and any verifier?
As above, s/its eventual destination/a given destination.
DKIM was designed to work from one posting to one delivery. It
was never intended to survive the vagaries of what can happen
between a delivery and a next posting. That it sometimes does
survive is nice, but was not a design goal.
So what is being sought here is a very basic and very substantial
increase in scope for DKIM.
Is this another example of what you described above as the perceived
use case vs. what's actually happening?
Perhaps:
"DKIM provides a way to detect that the content of a message was not
altered between the signer and a verifier, even if this requires one
or more intermediate deliveries and re-injections."
Seems fine to me.
Several attempts have been made to address the issues that arise
with alterations made by intermediate systems. For various reasons,
these technologies have failed to provide the information to
reliably distinguish between legitimate mail, and replay or
alteration of messages by bad actors.
DKIM does not attempt to distinguish 'legitimate' mail from mail that
is not legitimate.
Luckily, the above sentence doesn't say that it does. The "attempts" and
"technologies" are not DKIM.
From the use here, I infer "unmodified since injection" to cover
content and something about the original, intended recipient set to
cover replay.
As for 'replay' it needs to be precisely defined here, especially
since there are different views about what it refers to.
+1
I'm not even sure it needs to be mentioned here, but yes, worth defining
if you do.
As for alteration by bad actors, I was not aware that that is
considered a problem for DKIM. In fact I thought it was /not/ a
problem. So this needs to be explained and documented.
This gets to "acceptable" mutations, whatever that means. Or
"innocent", maybe?
DKIM2 is (in part) attempting to define how to sign not only the
original message but also alterations made by intermediaries. Whether
those mutations are "acceptable" or "innocent" is left to the
verifier/evaluator.
Objectives
This working group will take a holistic approach to the underlying
problems of message alterations, error handling, and trust
relationships between the systems involved in handling an email -
from its inception to arrival at its final destination.
There are problems with error handling? What are they? I don't
recall seeing discussion of this. What is the actual work to be
done? What goals for improvement are sought?
+1
Agreed, that needs a bit more text.
Trust relationships are far -- very far -- beyond the scope of DKIM,
other than whether a DKIM signature can be trusted.
I think it's fine to discuss how trust relationships might couple with
DKIM to impact handling decisions, but how to develop or track trust
is probably rightly out of scope (unless someone has something in
mind).
Yes, I read it as how DKIM2 results can be used with trust relationships
to impact handling decisions, not defining trust relationships.
Given the considerable increase of scope for DKIM and range of topics
cited here for improvement, the charter should have a concrete
proposal to take as input, if only to provide an example of how one
might approach dealing with these topics.
I would prefer a good starting point as well.
I'm fine with Richard providing the draft he mentioned as a starting
point, but I don't think it is strictly necessary.
The working group will use the mechanisms of DKIM as a basis,
extending and modifying them to solve problems that have been
identified in real-world usage.
Since they have been identified, they should be documented here,
clearly enough to aid the working group in knowing whether something
is in-scope our out of scope.
+1
I think they have been identified ("issues that arise with with
alterations made by intermediate systems", inability to "distinguish
between legitimate mail, and replay or alteration of messages by bad
actors"), but I think being specific here is fine.
It will be necessary for any new design to work in parallel with the
existing mechanisms, and have a clear upgrade path.
If it is parallel, it is independent. So I don't know what it means
'to work' in parallel. And I don't know what it means to not work in
parallel.
I imagine the intent is not to disrupt the deployed DKIM base while
DKIM2
(or whatever) is being developed or deployed.
That was my belief as well.
To achieve its goals, this work requires a wide scope. The design may
supersede, modify, or replace many parts of the current email
infrastructure and associated reporting mechanisms - while retaining
the ability to support existing use-cases.
Oh. In parallel with existing /email/. You want to replace the
current Internet Mail infrastructure. Gosh...
I don't believe that was the intent, though I absolutely see how it
could be read that way. This may replace parts of the current email
*source authentication* infrastructure and its associated reporting
mechanisms, not the whole kit-and-kaboodle.
Forgive me, but, again, this is something for the IRTF, not the IETF.
I'm not convinced there's an IRTF project to charter here; this feels
IETF-y to me.
I agree. See above. This is engineering.
pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
