On 7/3/2014 11:04 PM, Pete Resnick wrote:
"As the working group develops solutions to deal with indirect mail
flows, it will seek to maintain the end-to-end nature of existing
identifier fields in mail, in particular avoiding solutions that
require rewriting of originator fields."
It is simply important that when solutions get discussed, if a
proposal is made for one that involves rewriting originator fields,
those of us who feel that it is a show stopper need to clearly,
concisely, and professionally lay out the arguments for why doing so
is very problematic.
And there is where my concern lies.
This puts an unnecessary heavy burden on proving why it was a long
time ethical engineering taboo to tamper with the "From" field of any
communications I/O in the annals of telecomputing, especially for the
purpose of breaking and getting around a new layer of mail security.
The mail comm I/O infrastructure was never designed for it and for
long time historical good, legitimate and legal reasons.
Do we need to go into a justification why 5322.From is the only
required header to be hash bound to the DKIM signature? Thus making
it technically impossible of disassociating the purported author
identity from the signer identity?
Maybe we should do a DKIM errata to relax the 5322.From header hashing
requirement? Or do so with the DKIM v=2 talks?
The DKIM threat analysis work considered the condition where a bad guy
can purposely invalidate a signature and since DKIM mandates a MUST to
ignore the signature as it was never signed, it was still possible to
still protect the domain using a DKIM signature author domain
authorization protocol policy. This was not something the signer
domain could handle because it was invalidated. While the rewrite idea
opens the door for good intention guys to bypass downlink DKIM related
security checks, it opens the door on the bad guys to do the same thing.
A good chair should recognize the technical
issues and will not call consensus if they are not satisfactorily
addressed. Appeals are for when things go wrong, not when we're
worried about things going wrong.
Engineering training and experiences gives us the ethical and
engineering insights to know what is right and wrong. We don't need
to waste time in waiting for the obviously bad thing to go wrong
before action is taken and with the IETF appeal process, its generally
too late. I am absolutely worried that indirect endorsement or
redesign considerations for rewrites will not only seriously damage
DKIM and any policy work, it can have a drastic impact on decades of
integrated mail design expectations across the board.
[...]As a core mail principle, it MUST NEVER be valid to tamper with
5322.From, especially as a way to bypass a security protocol.
The entire idea needs to be out of scope.
So do I understand you to say that you think the text is not strong
enough?
Probably. Whats stronger than strong? Outlawed?
By specifically highlighting it in the charter text as you suggest, it
is presented as the specific alternative solution to the DKIM
signature identity authentication/authorization problem.
It is not an alternative solution in the same way a double From wasn't
a alternative to bypassing DKIM security checks. It should to be
presented among the potential serious security problems and not as the
"path of least resistance" alternative to get around a mail security
wall.
Thanks
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
