-----Original Message-----
From: John R. Levine [mailto:johnl(_at_)iecc(_dot_)com]
Sent: Thursday, April 28, 2011 12:15 AM
To: MH Michael Hammer (5304)
Cc: Murray S. Kucherawy; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: RE: [ietf-dkim] Output summary
a) If at least one signature verifies, report success with the d=
value(s) of the valid signature(s) and optionally other stuff.
I'm not comfortable with this statement. If I have two signatures,
one
from the domain in the From and one from a random 3rd party and the
From
domain signature fails and the 3rd party passes then we declare
success
with the 3rd party d=signature? To me that dog won't hunt.
That is quite specifically what 4871 says. To do anything different
would
be a major incompatible change. We have explicitly rejected the idea
that
"first party" signatures are special in DKIM. (They are in ADSP, but
that's ADSP.) Among the reasons we rejected the "first party" stuff
is
that it would make DKIM unable to work usefully with mailing lists
like
this one.
The fact that the standard itself does not explicitly go into the "first
party" stuff was a compromise. It doesn't mean that the concept isn't
out there. The logic you are laying out for multiple signatures is
exactly the same flaw that SIDF has where it demands that if a
(arbitrary) Sender field is present then that is the PRA. It allows
attacks to game the system. By allowing someone to break the original
signature and then sign with a signature from some arbitrary domain (I
think we are all aware of the concept of throw away domains) that
passes, it is game the system time.
b) If nothing verified and nothing tempfailed, report no
signatures.
c) If nothing verified and something tempfailed, return a hint to
try
again later.
And what exactly might this hint be? (not being sarcastic, probably
just
dense). How much later? How many retries? How likely is the verifier
to
be willing or able to hold large queues to accommodate tempfails? If
not, is this a potential attack vector against the receiver?
Those are all reasonable questions, but I don't think this is a change
from 4871, which suggests using SMTP 451 codes to force the sender to
resend the message later, for whatever the sender's interpretation of
later is. Can't get much vaguer about retry strategy than that.
There has been quite a bit of discussion about how the DKIM evaluation
is occurring after acceptance by a border MTA in many environments. Do
we really want an architecture that does what you are saying?
d) If at least one signature verified and at least one tempfailed,
uh,
flip a coin and either report success or a try again hint.
Ugh, no way on d). For multiple signatures where one or more is a
tempfail, it should really be that each one gets its own output
(signing
domain plus result) and leave it to the consumer of the output to
determine what to do. What happens if you have 3 signatures? It gets
messy real quick.
The current language in 4871 says in more than one place that you
ignore
signatures that don't verify. It also contradicts itself by
suggesting
that you don't quite ignore a tempfail but somehow arrange to try
again
later.
If we require a verifier to report the details of signatures that
don't
verify, that strikes me as a significant incompatible change.
Coin flipping is a rigorous scientific method of achieving consistent
outcomes.
I'm beginning to wonder if DKIM is truly ready for standards track. I'd
take a significant change that simply says report details including ones
that fail to verify over coin flipping and contradictory language.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html