More like “customer sees that DKIM is used to authenticate DNC leaks, decides that DKIM is a terrible idea for a political entity to have on, let alone any random business”.
I don’t really get your proposal here - how does it prevent post-delivery authentication via the RSA key? > On Jul 11, 2020, at 07:44, Andrew C Aitchison <[email protected]> wrote: > > On Fri, 10 Jul 2020, Matt Corallo via mailop wrote: > >> For various reasons, DKIM's non-repudiation property has always >> prevented us deploying DKIM signing on our mail. The obvious fix for >> this is to roll DKIM keys aggressively (eg every few minutes) and >> publish the private keys for revoked keys as you go. Given relay >> times for mail through various hosts, how aggressive could one >> theoretically get without having keys time out before mail is >> verified (ie how long must DKIM keys remain valid after mail has >> been signed by them?). > > How does this thinking go ? > > You use a dedicated ip address whose name clearly identifies the customer. > You publish the private key and *do not* roll it over (more often than > everyone else). > You are a low volume sender and don't stick your head above the parapet, > so no one bothers to make an exception to the DKIM pass. > The "maths" is simple enough for the judge and jury. > there is a little misuse by spammers, so the client has plausible deniability. > > Problems: > Spammers misuse you in large volume so you become visible to mail operators > and get blocked. Yes, that is a risk that the client signs up for. > You can roll the keys to be a good netizen, but that makes plausible > deniability less tenable ... > > ---------------- > > Can you have two DKIM signatures, RSA and ECC ? > If so does the following work ? > You can use the simple hash-based revokation to roll the ECC key > and limit the spam enabled by a fixed known RSA key. > > I'd be asking danager money for the active effort with all this key-rolling > to let the client have their cake and eat it ... > > -- > Andrew C. Aitchison Kendal, UK > [email protected] > > _______________________________________________ > mailop mailing list > [email protected] > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop _______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
