On 7/10/20 8:59 PM, Brandon Long wrote: > > > On Fri, Jul 10, 2020 at 5:39 PM Luis E. Muñoz via mailop <[email protected] > <mailto:[email protected]>> 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> > <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.
Sure they are, just publish the private key afterwards (this is part of how OTR works if I recall correctly, in fact). If you had a prefect way of knowing when a mail has gotten to its destination (and, thus, its DKIM signature doesn't need to be verified again for delivery purposes), you could remove the relevant key from the DNS, wait for it to time out, and then publish the private key. Now anyone with a copy of openssl can "forge" an "authenticated" email using that key, but no mail servers would reasonably accept it, protecting DKIM's original goal. (note timestamping concern noted above, but with tight enough timing, its likely OK). > 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. That's true, and its certainly the case that most people will happily believe what their friend shows them in their GMail account (nevermind that you can log in with IMAP and put anything you want there, or at least you can with most providers). > Anyways, ecc has been added to DKIM, but I'm not sure how widely deployed > verifying it is. > https://tools.ietf.org/html/rfc8463 Oh, cool! Not sure how I missed that. _______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
