On Tue, Jun 10, 2014 at 8:41 AM, Vlatko Salaj <[email protected]> wrote:
> > i'm still waiting for u to address the spoofing hole > u left wide open with this approach. > > no, i won't accept "short-lived" as a solution, cause that's > easy to circumvent. > > It means you have a limited time to reuse a delegation signature. Also, as defined, you have to be able to impersonate one of the domains in the To: and/or Cc: field because one of those domains has to DKIM-sign the altered content, and that signature has to pass for the receiver. If you can do both of those things, then yes, the attacker "wins". Not everything has to be bulletproof to be useful as either an experiment or a starting point for further discussion. The document already calls this out as a known risk; that's specifically what Security Considerations is for. The fact that there are risks doesn't automatically mean this proposal fails. If people aren't prepared to accept the risk, then they don't have to do what's described here, and maybe it quietly fades into history. Otherwise, if this solves a problem for them and the risk is palatable, then it might be useful to them. >> introduces whitelisting which, kind of, breaks its premise. > > I don't see how this introduces whitelisting requirements. > > === > section 3, DKIM-Delegate > > [...] it asserts an ephemeral relationship between an original > message signing domain and a later intermediary (Mediator). > === > > this is, ESSENTIALLY, a whitelisting approach. > > and we have much better whitelisting solutions already. > You must be using a different definition of "whitelisting" than I am. To me, a whitelist is something you have to query to provide elevated status to some identifier that might be on that list. There's no query happening here, unless you consider that DKIM-Delegate is carrying the whitelist with it implicitly for every message. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
