1. 42

  2. 14

    There are some harsh comments on the blog post. Some people seem to think that the author is inherently against non-repudiation per se, but it seems to me he’s not. He’s against DKIM as a non-repudiation mechanism, hence his proposal.

    If you want non-repudiation, fine. Just use something else than DKIM that provides that property by accident.

    1. 9

      In practice, some people rotate periodically (I do so every three months, some people once a year), most seem to never rotate. Publishing the private key some time post-rotation makes sense to me and I will look into doing so, and probably TXT records in DNS pointing to the URL of the historical private keys.

      The biggest issue is going to be that Google didn’t plan for this and so can’t rotate this easily.

      For a mail provider for a domain, where they do not control the DNS of the domain, you need to plan out a multi-selector strategy. I went into this recently:

      All the users of (Google Apps for your Domain)/(GSuite)/(Google Workspace)/whatever? All of those who’ve set up CNAMEs in DNS for Google’s one selector? They’re screwed if Google change today. Last time they rotated, they had very few such customers, and the key was compromised, so they went ahead and did it anyway. Today?

      Google needs to set up a multi-selector strategy, then publish advice to their customers, then repeatedly audit the DNS for all the customers configured to use their service until they can see handling in place. This is going to be a headache.

      1. 5

        Interesting proposal.

        It seems in the subtext the author is politically motivated to suggest this change, but I will ignore that aspect.

        If keys are regularly rotated, this adds certain guarantees to email ordering. You can prove an email was sent in a given two week window. This does help with verifying correspondence after the fact.

        However publishing private keys leads to very poor secondary effects. Suddenly you can’t be sure an old email is legitimate. Users testing dkim signatures will not know this. Despite being public knowledge, nobody has perfect information and this will lead to further negative social effects as people verify and break and verify leaked emails. I don’t think this proposal will actually fix anything for the negative social outcomes of proving a political figure actually sent a given email.

        1. 6

          It seems in the subtext the author is politically motivated

          The author mostly seems to be interested in closing a side effect of DKIM which wasn’t anticipated at the time of its design/adoption. As a few people have pointed out in the various heated comment threads on other sites, the only thing you need for secure messaging is for intended recipients to be able to authenticate the message at the time it’s received. The system’s security doesn’t depend in any way on also supporting authentication at later times or by other entities, and in fact many secure messaging systems explicitly prevent that with deniability features. But nobody seems to have thought about it for DKIM, and now we have some high-profile cases where deniability would have been really useful for the victims.

          Too many people are also reacting to the specific cases and basically going “GRAAR I WANT THAT POLITICIAN TO SUFFER” and thus talking themselves into not wanting deniability here, rather than considering the other consequences, like whether you want deniability for dissidents who use secure messaging systems – I suspect many of us do, and deniability for the dissident is not possible without also providing it to the politician.

          1. 6

            Suddenly you can’t be sure an old email is legitimate

            Who is the ‘you’ in this context? There’s nothing stopping a receiving mail server from doing the DKIM verification and adding a header that contains the time stamp at which it verified. This guarantees to anyone that trusts their mail server that the DKIM signature was valid at the time that the mail was received but it doesn’t extend that guarantee to third parties. You could sign that header with a private key that is frequently rotated and never released, keeping a log of all of the public keys elsewhere, so that someone compromising your mail server would not be able to forge a DKIM verification in the past.

            If you then publish these keys in some externally verifiable ledger, then third parties might be able to verify the signature, but they’d still have to trust that you rolled over the private keys (if your mail server kept a copy of the old private keys, you’d be able to forge signature verification in the past, so it’s easy for someone else to claim that your validations are invalid).

            Now, if you really wanted to be able to publicly attest to all emails that you’ve ever received, you could run the verification in a confidential computing environment, for example a CCF service that verified the signatures and published the hashes of every verified signature in a publicly attestable append-only log, but unless you’re expecting to receive emails from someone who you can then blackmail over the contents of the emails, there’s no real incentive for anyone to do that.

            1. 1

              Merkle tree of objects consisting of Message-Id, Date, DKIM signature, verification results. Periodically use a public timestamping service to sign the top of the tree.

          2. 3

            What happened to don’t use e-mail for stuff you don’t want to get leaked in the future?

            Very few comments about the advantages of having DKIM as a non-repudiation mechanism, such as if I need to prove I received an email at the specific date and/or time:

            • My ISP sent me an email letting me know my Internet service will be upgraded for free to a higher tier, and then fails to do this (has actually happened)
            • My landlord agreeing to lowering my rent for the remainder of the year, and then not admitting he ever said this
            • A lot of other reasons why I prefer having DKIM’s side effects

            I can’t imagine myself convincing/forcing my ISP to start using OTHER methods such as GPG, S/MIME and whatever else. Or my VPS provider, or my landlord. While I do feel for the politicians/journalists/whistleblowers and other persons suffering from the side effect of DKIM, I assume the rest of the population would mostly benefit from having messages authenticated.

            1. 1

              The article seems to have the perspective that if the DKIM signature cannot be verified, or can easily be forged due to private keys available, then it would not be believable that “leaked” e-mails originate from the person named. Given how many people appearently believe in Nigerian princes contacting them, I think that most people probably simply do not care of this thing called “DKIM” if they even know about it. They will simply say that until otherwise proven, the person listed as sender is the sender. Thus, I think the article argues against a non-issue.

              1. 4

                I argue from personal experience that it is an issue: any time there’s an explosive leak, I have friend or relatives asking me either whether the mails can be shown to be genuine/fake, or “what’s this DKIM signature thing which the newspaper says proves it’s genuine, are they right or full of fecal matter?”

                There may be a lot of people who’ll believe whatever they’re told, but there are also many thinking adults who, when presented by something almost too-good/bad-to-be-true, turn to people they know and trust and ask for confirmation.

                1. 1

                  They will simply say that until otherwise proven, the person listed as sender is the sender.

                  So, consider a hypothetical that I think a lot of people here would be sympathetic to: a whistleblower wants to leak important, potentially scandalous information to a journalist, and knows that powerful entities want that information to stay secret and will retaliate heavily against the person who reveals it.

                  And consider a world where the DKIM-or-equivalent has deniability/repudiation features. Now the journalist could have a tool which takes a list of plausible alternate leaker identities and generates spoofed but cryptographically “valid” (for the timestamp at which they were sent) copies of the leaker’s email, from all of those alternative identities, and build their release of the information around that.

                  Is this a perfect solution to protect the leaker? No. Is it a significant and worthwhile additional layer of protection above what would be available with current best practices? Yes.

                  So why not do that?