On 1/25/25 4:00 PM, Richard Clayton wrote:
In message <78e99534-7b33-4e26-91c6-206035a91...@mtcc.com>, Michael
Thomas <m...@mtcc.com> writes
> I'm sorry can you give some examples of the "exotic changes to existing
> fields"? I'm drawing a blank on why you'd need to change existing
fields
> at all vs introducing new tags, and especially since introducing new
> mail headers is also an option.
the notion of giving the sender the task of deciding on which headers to
sign and then adding headers in twice to avoid non-RFC compliant
messages being erroneously accepted is exotic ... saying that this is no
longer required (as we do in DKIM2) will remove the exotic-ness but if
we have to support the old scheme in parallel then there is no gain
possible --
I'm sorry, I don't understand this or the supposed problem.
and if you handle emails at the billion scale you care about
even small efficiency gains
Given ARC which is implemented by probably the largest mailbox provider,
I'm rather dubious about that claim. My experience was that adding DKIM
was that it was pretty much a drop in the bucket in processing which
actually surprised me at the time, and that was 20 years ago.
the notion of catering for reordering of headers when almost no system
does (and if it does it could arrange to undo that) is exotic. DKIM2
will remove that (you won't find that in what we've written so far
because Murray has discouraged technical discussion)
Who is "catering" here? Who's doing the reordering? Are you trying to
say that reordering of signed headers is a problem? I don't understand.
If there is some sort of problem here, I think it should be a bullet in
the charter that explains it, which it doesn't appear to be.
the notion that simple is useful for headers is exotic ... the notion
that allowing a choice of relaxed or simple for bodies means that people
have to engineer for both -- that's exotic
Again, I don't understand this. You're obviously talking about the
canonical message text for the hash, but what exactly is the problem
with the current scheme with DKIM?
as you have already noted l= seemed like a good idea at the time, but is
now associated with serious security concerns ...
If l= has "security concerns" so would anything that a mutating
intermediary but annotates their changes would too. The receiver
reconstructing the original signature would be vulnerable to the same
malicious modifications that l= allows too. IMO, this concern was always
way overblown and was part of the general dismissiveness about mailing
list traversal at the time.
So either we're now at peace with allowing mutations and letting the
receiver evaluate them, or we're not. We can't have it both ways.
Mike
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
