> That's not true in all cases. Spam and phishing slips through filters, etc, > regularly and doing forensics may happen well past delivery windows. Part of > DKIM is a "blame me" mechanism. If you remove the signature how do they know > they are actually responsible?
Perhaps the domain can keep the signatures separate, just not when sent out to the MUA. Or we can figure out something more creative. > . And even if you remove the signature, there is a lot of other evidence that > a leaked email provides. DKIM with Her Emails made a pretty watertight case > that they were real, but even without it it would have been really hard to > disclaim them, especially if people get access to the receiving domain's logs > in a legal setting. Not all versions of adversarial attribution are done publicly or in a legal setting, and journalistic authentication is always possible. This is materially different than not offering any protection to users at all, and offering authenticated proof of private communications. A user may be able to disclaim specific messages, for example, even if others appear to be correct (“that message was modified!”) I (and others) wrote a usenix paper on the subject. Perhaps taking a look at the paper’s motivation will be helpful in understanding our complaint with how DKIM works now: https://www.usenix.org/conference/usenixsecurity21/presentation/specter-keyforge ==Mike > On Dec 6, 2022, at 2:50 PM, Michael Thomas <m...@mtcc.com> wrote: > > >> On 12/6/22 2:33 PM, Jon Callas wrote: >> >>>> On Dec 6, 2022, at 14:23, Michael Thomas <m...@mtcc.com> wrote: >>> >>> >>> On 12/6/22 2:05 PM, mikespec...@gmail.com wrote: >>>> I very much disagree with everything the above poster said. >>>> >>>> Deniability is a default property of all e2ee messaging apps; it’s both >>>> surprising and disheartening that email — a largely unencrypted medium — >>>> fails to provide deniability for its users. If we said that signal was >>>> behaving this way, or TLS, or any other e2ee protocol, we’d be up in arms. >>>> >>> If you want deniability you need to do it some other way. You have >>> absolutely no control over the receiving domain and little to no control >>> over the sending domain as well. Even if this wg produced a BCP, BCP's are >>> toothless and rely on good will when there may be none or can't be >>> bothered. Even unsigned mail can make for good circumstantial evidence. >> I'm very much pro-signature removal. >> >> I'm going to disagree with Mike a bit in that *deniability* is not what we >> want. What we want is not creating a mostly-valid non-repudiation. (Me, I >> don't think deniable encryption is possible, but that's another long >> discussion.) >> >> There have been a few cases where DKIM signatures were used to verify hacked >> email accounts. > Yes, imagine my surprise when I found out about Her Emails only about a year > ago. But that isn't the only use of forensics. >> >> However, as you know, DKIM authenticates the Administrative Domain not the >> user. We know that if someone were to be able to do simple SMTP forging to >> an outgoing MTA, the MTA would sign the message despite it not coming from >> the user. >> >> The purpose of a DKIM signature is, as our original statement put it, to >> make sure that a message from your bank actually came from your bank, even >> if it passed through your alumni association. Once it arrives to your real >> mailbox, that signature is not needed. > That's not true in all cases. Spam and phishing slips through filters, etc, > regularly and doing forensics may happen well past delivery windows. Part of > DKIM is a "blame me" mechanism. If you remove the signature how do they know > they are actually responsible? Or how do you complain to their upstream > provider without proof that it actually came from their customers? Especially > when it's not in their interest to accept blame. And even if you remove the > signature, there is a lot of other evidence that a leaked email provides. > DKIM with Her Emails made a pretty watertight case that they were real, but > even without it it would have been really hard to disclaim them, especially > if people get access to the receiving domain's logs in a legal setting. > > Mike >
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
