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. > 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. Matt _______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
