> -----Original Message----- > From: John R. Levine [mailto:jo...@iecc.com] > Sent: Thursday, April 28, 2011 12:15 AM > To: MH Michael Hammer (5304) > Cc: Murray S. Kucherawy; ietf-dkim@mipassoc.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
