On Sun, Aug 30, 2020 at 9:11 AM Alessandro Vesely <ves...@tana.it> wrote:
> On Sun 30/Aug/2020 14:07:33 +0200 Douglas E. Foster wrote: > > Since we are designing a system that allows a mediator to alter Subject > and > > Body, it should be no surprise that the conditional signature has the > potential > > for re-use. A well behaved mediator must be assumed before any such > trust > > delegation is granted. > > > > I see no way to ensure that the conditional signature is single-use. As > long as > > all of the signature's hashed content can be replicated onto another > message, > > the signature can be reused. > > Yes. That's true for any DKIM signature, in particular if using l=, which > allows to append varying content. > Indeed, RFC 6376 discusses replay attacks in a number of places. It would be nice if we could reduce that, but I suggest that's not a roadblock to this working group's progress since it's an acknowledged property of DKIM already. > DKIM uses the body content in two different hash calculations. This > severely > > limits the ability of an attacker to find and exploit a hash collision. > The > > conditional signatures seem unlikely to have that strength. > > Even if the hash covers few data, finding a collision is not any easier. > > According to dkim-conditional, an attacker would need a private key of the > domain pointed by !fs=. That limits exploits substantially. Using > vanilla > weak signatures (e.g. to be compatible with v=1 verifiers) allows > replaying at > recipient's discretion, a state of affairs loosely comparable to p=none. > The draft suggests use of "x=" as a way to limit exposure. If you do that, then an attacker would need to be able to generate mail through your signer with an "!fs=" tag identifying a domain they control, and exploit the replay before the time in the "x=" tag arrives. Sure, it's time-limited, but it only takes seconds for such an attack to succeed, and automation of such an attack is easy. If you attach a "!fs=" for any old domain, then the exposure is wide; if you can somehow constrain the domains, the attack surface is considerably smaller. In either case, reputation of the target domain might help, assuming that's a service to which the author domain's signer has access. For the cases of employers that want their staff to participate in, say, IETF lists, they might be willing to institute a program of registering domains where lists exist, thus limiting the attack surface. So you register "ietf.org" with your IT department, and they start issuing weak signatures on mail going to that domain for six months. As the deadline approaches, people are warned to re-register, else the registration expires and the conditional signatures stop; destructive results resume. Fraudulent registrations can be traced back to who made them. But we still have the Yahoo/GMail sized use cases to consider. I still don't think any kind of registration system could be reasonably expected to scale. Auto-detection, maybe, but that's got to be prone to false negatives (and destructive results) while the data warm up about a new destination. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
