On Fri, Jul 10, 2020 at 5:39 PM Luis E. Muñoz via mailop <mailop@mailop.org> wrote:
> On 10 Jul 2020, at 16:54, Matt Corallo via mailop wrote: > > Replies inline. > > On 7/10/20 7:50 PM, Brian Toresdahl wrote: > > Your approach and goals don't seem to make sense to me. > > TL;DR: The customer is always right, and the customer sees DKIM being used > regularly to authenticate leaked emails - if > old not-in-use keys are public, anyone can sign anything they want, and > suddenly you can't authenticate mail with them, > at least after-delivery, that is. > > Not sure I understand your customer's use case completely, but DKIM is > meant to verify the signature upon delivery. You can certainly try and > verify again at a later time. > > You do not need to have a *small* number of public keys published. You > can have a very large pool of them, and theoretically use them to sign a > single message when sending. A while after delivering the message, you can > remove and destroy the key material – DNS public key and private key – to > prevent its reuse. > > This could be an interesting project – which would be stretching the > intended use case for DKIM IMO :-) > > DKIM works (I'm summarizing a lot) by signing mail, and the public key to > check that signature is placed in a "selector" > record in DNS (selector1._domainkeys.example.com < > http://domainkeys.example.com>). If you want to rotate DKIM keys, you > can immediately start signing new mail with with another selector > (selector2._...), keeping the selector1 around long > enough for the old mail to be delivered and checked. Are you asking how > long selector1 needs to stay around? For some > sort of 95th percentile, probably less that an hour. > > Yes, that was my question, thanks :). Sadly, I don't think and hour would > work - plenty of time to timestamp the emails > in question and suddenly the email is non-reputably signed again. Back to > the drawing board, I suppose. > > I was lost by the end of this paragraph. > > The goal is to actually publish the private key, no need to wait for > someone to brute-force it :) > > Are you sure you're not better using S/MIME or GPG to produce *signed* > email payloads? > I don't think any of these types of signatures are repudable. I don't know how you can authenticate something and also make it forgeable so no one can prove it was you. Maybe if you extended what you're saying above, have a large number of keys, and only serve them to the recipient... but with DNS caching, that would be hard to enforce, especially for mail to Google where we use the same Honest DNS that the world can use. Or you could use a "weak" key so that anyone with effort could break it. This is now against the RFCs and many receivers would treat the messages as non-signed. Anyways, not a cryptography expert, so I won't say I know the full breadth of this space. This came up after the Democratric Party email release in 2016, there were some attempts to claim the email wasn't valid, but DKIM (and ARC) said otherwise for as far as that would go. I'm not sure "public opinion" or even courts would be overly swayed by math, though. "We have this fancy mathematical method where we can prove that someone else could have forged this!" doesn't seem likely to be persuasive on a national stage where plenty of folks already believe things that are demonstrably not true. Anyways, ecc has been added to DKIM, but I'm not sure how widely deployed verifying it is. https://tools.ietf.org/html/rfc8463 Brandon
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
