On 12/2/20 2:53 PM, John R Levine wrote:
Which could trivially be added as an extension to DKIM and Auth-Res
negating the need for the Seal altogether since DKIM can directly
sign the old (renamed) auth-res. I can understand for an experiment
not wanting to touch dkim or auth-res, but for something standards
track less is more.
I still don't get it. I suppose the ARC group could have done
something to register extra tags for DKIM-Signature and A-R and tried
to do something about the fact that if a message passes through the
same network twice, the first A-R will be deleted, and try and find
and turn off all of the places where mailing lists helpfully delete
DKIM signatures that no longer are valid, and what they came up with
wouldn't work a whole lot worse than ARC does.
But why bother? The IANA header field registry currently has 419
entries. Why is it a crisis if it increases to 422 rather than 420?
It does a lot more than that:
1) It adds two new signatures to an already existing DKIM signature that
mailing lists add
2) It adds a new security mechanism (Seal) and adds a new attack
surface, when the old (renamed) auth-res could just be DKIM-signed which
has been thoroughly vetted
3) It adds a lot more bloat to the headers
4) Signing is a *far* more expensive operation than verifying, and you
negated any supposed advantage by adding two new signatures to verify
for lists that unhelpfully strip the original signature
I see a lot of anecdotes and speculation going on here and very little
hard data. This has been going on for at least a year. Since this is an
experiment, that is very worrying. More worrying is that I can't get a
straight answer on what exactly the value is of the mailing list's
auth-res is to filtering decisions. That seems to be the lynchpin to all
of this, but from what I'm seeing it's like an article of faith.
Mike
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
