On Fri, Jul 10, 2020 at 5:59 PM Matt Corallo via mailop <[email protected]> wrote:
> > > On 7/10/20 8:36 PM, Luis E. Muñoz 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. > > Hmm, that may have been confusingly worded, I admit. The point is that > we'd like to publish the private keys after > delivery. This means that if anyone goes and verifies an email with the > DKIM key *after* delivery, they learn nothing - > anyone could just go download the private key, so anyone could forge an > email. Of course by this point the keys in DNS > would have to be gone and TTL-timed-out so no risk of forged mail actually > being delivered, only making it possible to > fake a "DKIM-valid" mail by uploading it to gmail via IMAP. > > > 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. > > The goal isn't to prevent reuse, its to trivially allow its use. That > said, I admit your proposed method here may also > work, assming you don't DNSSEC-sign the domain (otherwise DNSSEC + DKIM > would represent a non-reputable signature). > > > This could be an interesting project – which would be stretching the > intended use case for DKIM IMO :-) > > Sure, but if it exists, and we're forced to use it to get deliverability, > gotta do something :). > > > 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. > > Being able to forge a DKIM-signed message after-the-fact isn't enough to > prevent DKIM from being transferable proof of > authentic email if the recipient can show both the DKIM signature, *and* > prove that it was generated prior to that > private key's disclosure. Sadly, there exist robust, trustworthy systems > for proving that some data existed prior to a > given time, at least if you're OK with few-minute/few-hour granularity. > Thus, your rotation has to occur within the time > window where a timestamp hasn't completed. > If it was a one-time DKIM key, you could publish it after being read one time or with some short timeout. To many providers, delivery is a matter of seconds. Of course, someone could take advantage because the key would be cached up to some TTL. > 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? > > The goal isn't to sign emails, in fact ideally we wouldn't have to at all. > The goal is only to get the deliveability > advantages of DKIM *without* signing (or at least without non-reputably > signing) email. > I'm curious what the incremental deliverability advantages are of DKIM over SPF. That seems like it might be worth the trade-off for your use case. Brandon
_______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
