ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Output summary

2011-04-27 23:02:22


-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of John R. Levine
Sent: Wednesday, April 27, 2011 6:33 PM
To: Murray S. Kucherawy
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Output summary

As for TEMPFAIL, you'd have to know which signature(s) were temp-
failed in order to decide about a later retry, which then leans us
back
toward giving the whole list of signatures that were present and a
status for each.

I wouldn't be opposed to doing so, except that 4871 says in two
separate
places not to do that.  Section 7 is, now that I look at it, really
badly
written, since it implies that a "verifier" is an SMTP server.

We probably have reasonably good agreement about what a verifier
should
do:

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.

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? 

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. 

I don't think we have had a thorough discussion on multiple signature
issues along this thought line and I'm not sure throwing something in at
the last moment during last call is the way to address it.

Unfortunately, that's not really what the existing language says.

Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet 
for
Dummies",
Please consider the environment before reading this e-mail.
http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>