[HN Gopher] DKIM: Rotate and publish your keys
___________________________________________________________________
DKIM: Rotate and publish your keys
Author : JNRowe
Score : 204 points
Date : 2023-10-01 07:44 UTC (15 hours ago)
(HTM) web link (diziet.dreamwidth.org)
(TXT) w3m dump (diziet.dreamwidth.org)
| throwawaaarrgh wrote:
| Publish your ssh private keys!
| op00to wrote:
| My voice is my passport!
| upofadown wrote:
| OK, rotating the DKIM keys allows someone to send an email and
| then later claim that the email was a forgery. But the fact that
| the DKIM keys are rotated is going to be generally known. So how
| could this possibly work?
|
| Someone comes to you and claims that a particular email was
| forged. They have no evidence of this forgery and no evidence
| that someone was even motivated and capable of doing such a
| forgery. You check and see that DMIM rotation is being done.
| Wouldn't the fact that there was a system set up specifically to
| allow someone to send an email and then lie about it make you
| very suspicious that they had done exactly that?
|
| Forwarding an the email to a third party entirely defeats this
| scheme, doesn't it?
| remram wrote:
| > Wouldn't the fact that there was a system set up specifically
| to allow someone to send an email and then lie about it make
| you very suspicious that they had done exactly that?
|
| Not really, not when people have been arguing for this setup as
| a best practice for years for whole domains.
| joveian wrote:
| The argument is that the system as a whole shouldn't be set up
| in a way to provide (possible, limited) non-repudiation,
| similar to how postal mail (at least in the US) doesn't provide
| non-repudiation. It is not something that most people
| individually would have a say in how it is set up. Publishing
| expired DKIM keys wouldn't let you claim to the recipient that
| the message was forged but would make it harder to convince
| third parties in some contexts that the message is likely to be
| authentic.
|
| The advantage of deniability is that someone who manages to get
| one email of yours by any means can't prove to the world that
| you sent it, which can be an issue with things that are
| socially considered unfavorable as well as unsympathetic
| situations like corrupt politicians. There are disadvantages
| relating to harassment and corruption.
|
| The article doesn't mention it but trusted timestamping during
| the validity of the DKIM key (plus as always having a copy of
| the public key) preserves the (limited) non-repudiation.
| Forwarding during the DKIM key validity could potentially work
| as a reliable timestamp depending on the details of the
| forwarding.
| compsciphd wrote:
| This came up with the hunter biden laptop, DKIM doesn't really
| validate that you sent an email, but that an email was sent
| through that server at some point in time when said signing key
| was still being used.
|
| i.e. I demonstrated to others that I could have a DKIM signed
| email sent through gmail that was from a spoofed from: and it
| passed all DKIM tests (i.e. telnet gmail smtp server 25 (well
| with ssl, so openssl connect or something). smtp auth and do the
| standard MAIL FROM "SoSo <so@so> RCPT TO so@so data...... and it
| will look like a legit mail sent from SoSo.
|
| DKIM's job isn't to protect against that.
| logifail wrote:
| Q: If 2FA is enabled on a Google account, does SMTP AUTH still
| work?
|
| I've just tested this, I generated a new app password in my
| Google Account and used that to send Gmail from Python.
|
| Works fine when sending "from: <me@gmail>" with the app
| password, yet I can't change the sender since the SMTP auth
| then fails
|
| "5.7.8 Username and Password not accepted. Learn more at
| https://support.google.com/mail/?p=BadCredentials"
| dizhn wrote:
| You can set identities in gmail from which you can send
| emails. If it weren't gmail but a mail server you hosted, it
| would be even more trivial. Neither of these have to do with
| SMTP authentication. Without significant other configuration
| the mail server does not care what Mail From: address you
| enter. This is how my classmates were able to get emails from
| the US president back in the day.
| logifail wrote:
| > You can set identities in gmail from which you can send
| emails
|
| Right, and there's a verification step in which you confirm
| you own (or at least control) the additional email
| address[es]:
|
| https://support.google.com/mail/answer/22370?hl=en-GB
|
| The OP appeared to be talking about somehow persuading
| Gmail into DKIM-signing an email from an address that
| wasn't theirs, though?
| dizhn wrote:
| The immediate parent?
| logifail wrote:
| The post (https://news.ycombinator.com/item?id=37723688)
| to which I replied, although perhaps I'm misunderstanding
| this bit:
|
| "I demonstrated to others that I could have a DKIM signed
| email sent through gmail that was from a spoofed from:
| and it passed all DKIM tests (i.e. telnet gmail smtp
| server 25 (well with ssl, so openssl connect or
| something). smtp auth and do the standard MAIL FROM "SoSo
| <so@so> RCPT TO so@so data...... and it will look like a
| legit mail sent from SoSo"
|
| I've tried several times to do what I think is being
| claimed here and I'm struggling. For instance, telnet to
| a public mailserver I control, SMTP AUTH with an account
| with relay permissions, MAIL FROM so@so, RCPT TO my own
| Gmail, refused by GMail due to so@so's DMARC policy...
| dizhn wrote:
| Perhaps the domain in the article has a lax policy as
| most domains still do. Or what's failing is SPF alignment
| for you and not dkim.
| compsciphd wrote:
| So I just tested it again (took a while as forgot needed
| the -crlf option in s_client)
|
| So, gmail does rewrite the From: header (well it keeps
| the name, but replaces the email within the <brackets>
| and adds a X-Google-Original-From header), and as this
| story is about senders (not receivers), spoofing would be
| protected in that regard.
|
| However, what I remember now, is that I was proving that
| it doesn't tell you anything if the person in the To: was
| actually sent the mail.
|
| i.e. even though DKIM protects the "To:" and "From:"
| headers it has nothing to do with the Rcpt To: (i.e.
| think how BCC works). So DKIM doesn't prove that an email
| was actually sent to someone (even if its on their
| machine now), just that someone might have faked a scheme
| where they sent an email with a To in the headers to
| someone, but the RCPT TO was not that person. So, it get
| signed as such, but isn't true. And in the case of gmail,
| the only reason there's any form of protection on the
| From: header is because gmail enforces a level of
| protection outside of dkim.
|
| So what I must have done back then, was send people
| emails that looked like they were meant for Hunter Biden
| to receive that had all the DKIM validation check out,
| but were obviously never sent to him. (with all that
| said, for someone to have actually done this to Hunter
| Biden, they would have had to be playing such a long
| game, it's almost inconceivable to me, I was just proving
| that DKIM doesn't actually tell you if the supposed
| recepient is actually the receipient when sent via gmail,
| but as others have noted, if the From: header in the
| email isn't as locked down as gmail (and I'm sure not all
| are) / one knows of an exploit in gmail to subvert the
| From header in place editing, then it doesn't even help
| with that).
|
| anyways, I apologize for exaggeration in my original
| post, its wasn't quite accurate. I hope I cleared up any
| confusion I caused.
| logifail wrote:
| > So DKIM doesn't prove that an email was actually sent
| to someone (even if its on their machine now), just that
| someone might have faked a scheme where they sent an
| email with a To in the headers to someone, but the RCPT
| TO was not that person.
|
| We find the DKIM headers on the recipient's copy of
| messages, and they confirm information about the
| authenticity of the sender, right?
|
| So a malicious actor in league with Alice prepares a
| laptop which purports to be Bob's (but isn't).... and on
| it there are DKIM-signed messages "From: Alice
| <alice@example.com>" and apparently "To: Bob
| <bob@example.com>", except they didn't actually go
| anywhere near Bob because they were "RCPT TO:
| <someone_else>"?
|
| ...or is there more to it?
| compsciphd wrote:
| that's it.
|
| I'd think that if one attacks the sender, one could even
| do it without the purported senders cooperation could
| also cause it to happen.
|
| Now, especially because google rotates DKIM keys this
| would be such a long game attack that in my view, it's
| very improbable to be such a scenario.
| logifail wrote:
| > [without] the purported senders cooperation
|
| Thinking about forging mail, in the case of senders who
| control their DKIM signing keys (me, for instance), if
| you have the sender's cooperation then you have access to
| their private DKIM key, can't you just sign any message
| you like?
|
| No need for the messages you're forging and signing to go
| anywhere near any email clients or mailservers at all.
| compsciphd wrote:
| yes, for example, an insider at google could conceptually
| have forged a mail. just don't consider that probable. I
| think its more important to understand the limitations of
| what DKIM is telling us.
| sschueller wrote:
| Wasn't it also Hillary Clinton's emails that had DKIM and they
| denied that they wrote any of them? If that were the case it
| would mean someone has full access to that email system for
| years and sent all those emails through it.
| viraptor wrote:
| Link? From what I remember, the details in that case where
| handed over in cooperation. Was there anything actually
| denied? There was only the issue around retention/deletion of
| emails, but even that didn't include a tech proof AFAIK.
| talent_deprived wrote:
| Agreed, they may be recalling the Podesta emails:
|
| https://en.wikipedia.org/wiki/Podesta_emails
| WesolyKubeczek wrote:
| Awww yisss, publish all the private keys, let's have a DKIM-
| verified phishing bonanza while we are at it, too!
| dmarinus wrote:
| Is there any service which automatically indexes and archives
| DKIM keys?
|
| It could be very valuable to check the authenticity of old
| e-mails.
| talkingtab wrote:
| The article advocates publishing old DKIM keys in order to
| provide deniability. You create a new DKIM key, publish the old
| one. With the old dkim key forging an old email is relatively
| easy.
|
| Someone takes you to court and submits an old email that you sent
| as evidence. You can demonstrate that it is possible that anyone
| could have signed that email using the now-published DKIM key.
|
| It is interesting that you can do this. A question is whether and
| when you would want to do so. Someone points out that good or bad
| conspirators might want to this: you send out anti-Putin emails
| and can deny it. Other ones?
|
| Another point seems to be that DKIM is really designed not to
| verify emails, but to verify email senders.
|
| <humor> Understanding this, I wonder if there are other things
| you can do with email using the same DKIM signing kind of
| mechanism. Like what about an OSIM signature, that uses a key
| only issued to email services that are not Google or Hotmail or
| one of the other big email people. If the message does not come
| from an OSIM host, then the email is delivered but goes into a
| o_spam folder? <end humor/>
| kro wrote:
| Rotating (and removing old keys from DNS) without publishing the
| private keys would already make it really hard.
|
| For proving an old signature you'd lack an _authentic_ source for
| the signing public key that could only really be a dump of the
| historic DNS trace with all DNSSEC signatures (i.e. gmail does
| not use it).
| simplereally wrote:
| Publish your private keys and be considered responsible for what
| is signed with them, simple really :)
|
| I am not a fan of blockchains but this is a rare case where they
| could be used to prove that the message is authentic by
| publishing the hash of the message (including the signature) in
| it. If the DKIM private key was published after the message was
| added to the blockchain then the message was clearly legitimate.
| remram wrote:
| > Publish your private keys and be considered responsible for
| what is signed with them, simple really
|
| What makes you think that?
| simplereally wrote:
| I am not thinking of anything, I am simply proposing a
| solution as I fear that DKIM rotation might end up being used
| for gaslighting.
| rlpb wrote:
| No need of "blockchain" for that. Just do a hash drop to any
| publicly archived place, or use a timestamping service.
| londons_explore wrote:
| Is this actually a problem in practice?
|
| How many people have presented forged emails as real without a
| DKIM signature, and had the press say "nah, we're not going to
| report on that because DKIM is missing"?
| vintermann wrote:
| They absolutely will assume something was fake if it's
| embarrassing and they think it can't be proved. Most of them
| don't know about DKIM signatures, though.
|
| A lot of wikileaks mails were verified with DKIM, and as I
| recall some of the people sending them initially denied it.
| matthewdgreen wrote:
| Here is the tool the Associated Press uses to check DKIM
| signatures [1], and here is Wikileaks' page on DKIM [2].
|
| DKIM is routinely used to verify emails in cases where the
| evidence chain back to the source is unclear. I was personally
| involved in a forensic effort to verify DKIM signatures on the
| Hunter Biden laptop [3].
|
| [1] https://github.com/associatedpress/verify-dkim [2]
| https://wikileaks.org/DKIM-Verification.html [3]
| https://www.washingtonpost.com/technology/2022/03/30/hunter-...
| KirillPanov wrote:
| Captcha Check
|
| Hello, you've been (semi-randomly) selected to take a CAPTCHA to
| validate your requests. Please complete it below and hit the
| button!
| pacija wrote:
| SPF says which IP adresses are authorized to send email for a
| domain. DKIM should increase confidence that email is sent by
| authorized service on servers with those IP addresses (eg.
| Postfix) as opposed to unauthorized ones (eg. telnet). Finally,
| DMARC instructs receiving servers how to act on receiving email
| for a domain regarding validity of SPF and DKIM. It is up to
| receiving servers to respect this instruction or not.
|
| None of the above has anything to do with particular email
| message authenticity. Mechanisms for email authenticity, or
| additionally confidentiality, are S/MIME and PGP, where user
| controls the key, and it is up to them to make sure it doesn't
| leak.
|
| I am providing email service to close to thousand users on dozens
| of domains over the course of fifteen years. The article does not
| make much sense to me from either postmaster's or mail user's
| point of view.
| proto_lambda wrote:
| > None of the above has anything to do with particular email
| message authenticity.
|
| Only if you're on a shared email hoster. If you're the only one
| that has access to the mail server's signing keys, it's gonna
| be real hard to convince anyone that someone else signed that
| email.
| [deleted]
| tamimio wrote:
| The whole idea of DKIM and SPF checks and even DMARC policy is to
| fulfill the "integrity" part of the email communication by
| authenticating it to prevent unauthorized parties to send emails
| on behalf of a domain they don't own. For DKIM, the mail you send
| will have the public key, then the header is signed with the mail
| server private key, similarly, the recipient side use the public
| key to verify the private was used, and to make sure the email
| was not tampered with in the way. Now, that boring theory to show
| that the idea is to prove it was you (the domain) who sent it
| -keep in mind DKIM won't prevent spoofing, it's meant to prevent
| spam, you should combine DKIM with your DMARC policy to make sure
| the domain in Form is not altered-, so trying to find a way that
| you can says later "it probably wasn't me" defeats the purpose of
| these integrity checks, and doesn't even make sense to be honest,
| if you're too concerned about leaked emails, encrypted it with
| GPG, still not the most optimal solution since meta-data is still
| leaking, at the end of the day, emails are not meant for secure
| communications.
| scandox wrote:
| Presumably there is a transitional period during which the new
| DKIM key becomes active and the old inactive. Will some
| legitimate mails fail verification during that period?
| alphager wrote:
| No. You can have multiple DKIM DNS records (each identified by
| an id called selector). Each DKIM signature includes the
| selector. When you change keys, you create a new DNS entry with
| a new selector, then change the settings of the mailserver. New
| mails will then be signed by the new key with the new selector.
| Old mails can still be verified until you delete the old DNS
| entry.
| gorgoiler wrote:
| You can have multiple keys at once: serve the old keys while
| announcing and using a new key.
| p-e-w wrote:
| I don't buy this idea:
|
| > As a user, you probably don't want your emails to be non-
| repudiable. (Other people might want to be able to prove you sent
| some email, but your email system ought to serve your interests,
| not theirs.)
|
| Other people being able to verify that an email really was sent
| by me _does_ serve my interests, because such verification
| establishes trust. That 's like claiming signing a contract isn't
| in your interest, because others will be able to prove that you
| agreed to its terms.
|
| There are very few legitimate situations where you don't want
| non-repudiation (and in most of these, you shouldn't use a
| standard email system anyway), while in many cases, non-
| repudiation is legitimately valuable - for both sender and
| receiver.
| withinboredom wrote:
| I was a expert witness on a case where a dad had modified an
| email as proof to drop their daughter out of school. The mom
| was quite pissed that he did this. I used the DKIM keys to
| prove the email she submitted was true and his version was not
| the original. It was a fun case.
| upofadown wrote:
| Most people want messages sent to them to be non-repudiable.
| Otherwise they can be harassed and threatened with impunity.
| This sort of thing only seems like a good idea when you don't
| remember that a message has both a sender and a receiver.
| ric2b wrote:
| But the sender chooses an e-mail service that sends e-mail in
| a way they aprove of.
|
| The receiver has no control over that besides possibly
| ignoring those e-mails, therefore the e-mail services favor
| the interests of the sender over those of the receiver.
| nulbyte wrote:
| > Other people being able to verify that an email really was
| sent by me does serve my interests, because such verification
| establishes trust.
|
| DKIM, the technology considered by the article, does not prove
| this. The D stands for domain; it asserts nothing about the
| user that may have sent the email. Even if the domain is yours,
| you might delegate to another service or two, or you may have
| more than one user, or some automation in place. In any case,
| the recipient has little, if any, way to verify that and in all
| likelihood doesn't care that much; if they did, they wouldn't
| be relying on DKIM.
|
| > There are very few legitimate situations where you don't want
| non-repudiation...
|
| As a service provider, I'd probably want this. If it gets me
| out from the middle of someone else's dispute and doesn't have
| an ill effect on the service otherwise, I'd welcome it.
| A1kmm wrote:
| But there is a chain: 1) the mail provider only allows
| outgoing mail with a particular Return-Path / Envelope Sender
| / From header if it has done authorisation checks to ensure
| the sender is allowed to use that address, 2) the mail
| provider DKIM-signs their outgoing mail.
|
| The combination of 1 and 2 work together. Yes, the mail
| provider could impersonate you, or could fail to do (1)
| correctly, but that is a different threat model to one where
| having no verification at all is okay.
| precommunicator wrote:
| Sure. I don't know if that's the case only for Gmail, but after
| email is received, generally, it's verified and results, at the
| point of receiving are stored on your email server. He's
| talking about verification after that initial verification. And
| if you want your emails to be verified, you should be using
| GPG/PGP/S.MIME or other signing system anyways. DKIM only
| verifies server, not user.
| ilyt wrote:
| But it also verifies nobody tampered with e-mail after it
| left the server and that is still valuable.
|
| As in the DKIM signature doesn't mean it was really the
| sender that sent it, but it does say that it wasn't changed
| after that.
| manonthewall wrote:
| Then I think you'll have to use pgp or some other mechanism one
| layer up. E-mail ain't the way to do it, it's not built into
| the current protocol as it stands.
| Avamander wrote:
| There isn't such a layer for email that is widespread
| (there's certified email in Italy). PGP and S/MIME crucially
| lack time and validity stapling.
|
| In a lot of EU countries you can however digitally sign a
| container and mail that (under eIDAS those qualifying
| electronic signatures are legally binding, unlike random
| publicly trusted S/MIME signature).
|
| But I guess if your alternative is fax, then a lot of thimngs
| are better than that.
| michaelmrose wrote:
| If we retain a functional society with reasonable rights for all
| aren't the "victims" of non-repudiation going to be virtually
| exclusively bad actors?
|
| People at real risk should probably be using something more
| secure like signal whereas people like US senators using a
| platform to communicate that can't be audited at need should
| probably go straight to prison on principal.
| Frankmartin321 wrote:
| [dead]
| time4tea wrote:
| [flagged]
| LeonM wrote:
| So for work I consult on email security and every time this
| article pops up I get texts from everybody asking for my opinion.
| So here we go.
|
| Disclaimer: opinions are my own.
|
| A DKIM signature does not prove that an individual sent the
| email, the key is not personal. A DKIM signature proves that the
| sending service is a delegated sender for the domain. Meaning
| that a correct DKIM signature proves that the part _after_ the
| '@' symbol in the sender address is authentic. Not the part
| before that. If you want to use a personal signature, you can use
| S/MIME.
|
| If you are a delegated sender for the domain, then you can use
| any sender name (the part before the '@' in the sender email
| address). This is how email works. The password that is typically
| required to authenticate with your outbound SMTP service if only
| enforced by that host.
|
| So an email with sender address jane@example.com that is DKIM
| signed only proves that the email was send by a host that is a
| allowed to send email on behalf of example.com. It does not prove
| in any way that the email was sent by Jane.
|
| Also, as others have mentioned, none of the email service
| providers will give you the private keys. I'd like to add that in
| most cases this won't even be possible, due to the use of HSMs.
|
| So the proposed scheme would only work in a situation where you
| are owner of the DKIM key (thus in practice where you are the
| owner of the host sending the email), and where you also own the
| domain. It is trivial for a prosecutor to prove the owner of the
| domain, or the owner of the host that used the DKIM key. No
| amount of publishing keys will help you deny that ownership.
|
| In my opinion it makes no sense in signing your email (whether it
| is S/MIME or DKIM) to prove that the email is authentic, and then
| complaining that there is no way to deny that the email is
| authentic once stuff goes bad.
| rcxdude wrote:
| Deniability is a useful characteristic in cryptographic
| protocols: the idea is the authenticity of the message can be
| proved to anyone who checks before the key is published (i.e.
| likely the intended recipient of the message), but not to
| someone who checks later (i.e. likely someone who may wish to
| use the contents of the message against you). It's something
| Signal's chat protocol aims to achieve, for example.
| layer8 wrote:
| This is builtin with X.509 certificates having an expiration
| date, and also the ability to revoke them before expiration.
| Unless you have a cryptographic timestamp proving the
| signature was made before expiration or revocation,
| signatures stop proving authenticity once the certificate has
| expired/been revoked.
| rcxdude wrote:
| No, because people don't think like SSL libraries and
| there's a big difference between "you should trust this
| key" and "this key provides good enough evidence of
| authenticity to count as incriminating". To defeat the
| latter the key must be published.
| brightball wrote:
| Thank you for saving me the time on this. I was about to echo
| the same.
| petejansson wrote:
| > every time this article pops up
|
| I don't think this is the same article of which you're
| thinking. This is a tool to rotate DKIM keys and publish the
| old ones (in a sense, a scheme that replaces revocation).
| denton-scratch wrote:
| > in most cases this won't even be possible, due to the use of
| HSMs.
|
| Most holders of keys do not own an HSM.
| LeonM wrote:
| The majority of email comes from major email providers (think
| Google, Microsoft, etc). They certainly own HSMs.
|
| Hence my statement that this scheme only really works for
| self-hosted solutions, because you won't be able to obtain
| the keys from third-party email providers.
| gsich wrote:
| If it's used for DKIM is another matter. You don't have
| only 1 mailserver with a HSM if you are this big. Having 1
| HSM with the private key would create a massive bottleneck
| and SPOF. If they have a HSM for each server with the same
| private key, the key can obviously be extracted from the
| HSM, making publishing it possible.
| nmadden wrote:
| That's not necessarily true. You can cluster and
| replicate HSMs to provide scalability but it is common
| practice to forbid extraction of private key material. In
| many cases you can't change that setting without a
| complete reset of the device.
|
| Edit: to expand on this a bit. The clustering will
| involve exchanging key material in encrypted form between
| each HSM. But that exchange is typically protected and
| authenticated by keys that are themselves attested as
| having been created securely in hardware. You can't just
| inject your own keys to mitm that connection.
| gsich wrote:
| For mailservers though? It this scaleable if you
| start/stop machines on demand.
| nmadden wrote:
| It can be scalable if you're prepared to chuck enough
| money at it. (Response time latencies are another matter,
| but that is somewhat less important in email). I have no
| experience at all of securing production mail servers, so
| whether they do this or not I don't know and other
| replies here suggest they don't use HSMs at all. _If_
| they do use HSMs then it's not crazy to assume that they
| can't easily publish old private keys, but if they don't
| use HSMs then that is irrelevant.
| LeonM wrote:
| > the key can obviously be extracted from the HSM, making
| publishing it possible.
|
| As I understand it, it should be impossible to export a
| private key from an HSM.
|
| I'm not very familiar with HSMs though, so I might be
| wrong about this.
| nmadden wrote:
| The PKCS#11 standard, which is implemented by most HSMs
| defines two attributes that control this:
|
| - Marking a key as "sensitive" means that the raw key
| material cannot be exported, except in encrypted
| ("wrapped") form. Such an encrypted key can then be
| unwrapped to install it on another HSM. This key-wrapping
| facility is largely to allow backup or replication (but
| see below).
|
| - Marking a key as "non-extractable" also means that it
| cannot be exported even in encrypted/wrapped form.
|
| You generally configure a policy on the HSM to say that
| all private keys must be sensitive etc. It is pretty
| common (in my experience, dealing with banks primarily)
| to enable a policy that enforces all private keys to be
| sensitive and non-extractable. Proprietary mechanisms are
| then used to replication and backup of those keys (that
| effectively ignore those attributes/work at a lower
| level).
| gsich wrote:
| >As I understand it, it should be impossible to export a
| private key from an HSM.
|
| This is my understanding too. But if you have several
| HSMs which should all have the same key (needed for DKIM)
| then there needs to be some sync/export/import mechanism.
| peanut-walrus wrote:
| I can with almost 100% certainty tell you that none of the
| major providers use HSMs for their DKIM keys.
| tbrownaw wrote:
| Use how?
|
| From what I understand, they can do more different things
| than "private key never leaves the device" asymmetric
| stuff.
| DoctorOetker wrote:
| > In my opinion it makes no sense in signing your email
| (whether it is S/MIME or DKIM) to prove that the email is
| authentic, and then complaining that there is no way to deny
| that the email is authentic once stuff goes bad.
|
| It is also rather futile, since the prover can get the messages
| timestamped (myriads of ways, myriads of platforms), perhaps
| even steganographically in the correspondence, before the key
| is rotated.
|
| the denialists can still rotate after shorter and even shorter
| intervals, but at some point the client software can't keep up
| and verify the email provider during usage, or rather resulting
| absence of usage...
|
| it's pretty sad when technologists cave in under pressure from
| governments, politicians, lawyers and big firms keeping the lid
| on scandals... reducing the usage of cryptography to a purely
| symbolic cargo cult token or gesture...
|
| Cryptography configured for exhibition only... but not in any
| court.
| NovemberWhiskey wrote:
| > _In my opinion it makes no sense in signing your email
| (whether it is S /MIME or DKIM) to prove that the email is
| authentic, and then complaining that there is no way to deny
| that the email is authentic once stuff goes bad._
|
| We all understand that really only the domain part is being
| authenticated, but if people believe in the good user identity
| and authentication practices of the sending domain then it's
| going to hard to rebut the presumption that the email is from
| the apparent sender.
|
| If we posit that the purpose of DKIM signatures is preventing
| the injection of forgeries in the MTA chain, then authenticity
| is only an important property from the time that the message is
| sent until the time it reaches its addressed recipient. After
| that point, it's a bug, because long-term non-repudiation is
| _not_ a purpose of DKIM.
|
| Once a particular message is no longer traversing the network,
| there is no value (for DKIM purposes) in preserving the secrecy
| of the signing key.
| KennyBlanken wrote:
| > So an email with sender address jane@example.com that is DKIM
| signed only proves that the email was send by a host that is a
| allowed to send email on behalf of example.com. It does not
| prove in any way that the email was sent by Jane.
|
| You should probably stop "consulting on email security" if you
| don't understand that a DKIM-signed message proves the mailhost
| was authorized, and at least some of the headers could easily
| prove who sent the message.
| LeonM wrote:
| > a DKIM-signed message proves the mailhost was authorized
|
| That is what I wrote, I may have not have explained it
| correctly though, I was in a bit of a rush earlier today.
|
| DKIM signs (a selection of) the headers, and the message
| body. The sender address (the 'from' header) is typically
| included in the signed subset of headers.
|
| The domain (the part after the '@' symbol) authorizes the
| sender (the owner of the private key) to send email on behalf
| of the domain by publishing the public key (the DKIM DNS
| record).
|
| So, if the signature is correct, then you know the message
| body, and the headers included in the signature (such as the
| 'from' header) are authentic (not tampered with since the
| host set added the signature). You also know that the sender
| is authorized to send email on behalf of the domain.
|
| However, the sending host is free to place any arbitrary data
| in the headers, including the 'from' header, and sign it.
| There is absolute nothing that will prevent a malicious host
| from placing an arbitrary name before the '@' sign, except
| for integrity. So just because 'jane' was in the 'from'
| header, it doesn't mean that Jane actually wrote the message.
|
| > and at least some of the headers could easily prove who
| sent the message.
|
| No, none of them do. As I explained above, the sender is free
| to set the header values to any value. So just because there
| is a name in 'from' header, doesn't mean that that person
| actually wrote the email, or that it originated from one of
| that person's devices.
|
| If you publish the DKIM DNS record for some third party email
| service, then that service could very well send email as
| you@yourdomain.tld. Should that somehow "easily prove" that
| you send that email? No amount of email headers are going to
| protect you from that kind of malicious behavior, that's just
| not how email works.
|
| > You should probably stop "consulting on email security" if
| you don't understand [...]
|
| Please refrain from insults like that. Reading your comment
| mocking my profession like that really ruined my evening.
| rainsford wrote:
| You are technically correct (the best kind of correct), but
| in practice the nuance you're referring to does not make as
| much difference as you think. Yes, email senders _could_
| send email from whatever user they want or change the body
| from what the user wrote, but in practice of course they
| aren 't doing that for the kind of email providers like
| Gmail that most people use.
|
| If the deniability of a DKIM signed email reduces to "maybe
| Gmail spoofed emails from me", you don't have much of an
| argument. Yes, in a technical cryptographic sense, DKIM
| does not prove _you_ sent the email, but when combined with
| how most providers like Gmail work, it makes it very likely
| you did send the email in every practical sense.
|
| This isn't just a nitpicking nuance. In theory, rotating
| and publishing DKIM keys makes no difference to deniability
| since DKIM doesn't technically provide non-repudiation at
| the individual user level. In practice though, a service
| like Gmail implementing DKIM rotation and key publishing
| would make emails for a huge number of users more deniable
| going forward.
| disruptiveink wrote:
| Yes, this is the point. Most (nearly all?) of the
| publicly available providers a user is likely to use
| won't allow you to use their MTAs and set From headers in
| a way that would impersonate someone else on that domain,
| provided you're authenticated as yourself.
|
| So pointing out DKIM only authenticates the domain only
| weakens the argument from "UserX at Gmail sent this
| email" to "UserX at Gmail sent this email provided no one
| found a suitable, currently unknown exploit at Gmail or
| performed an inside job".
|
| For a journalist and most juries, provided the absence of
| any reasonable suspicion or evidence of weaknesses / foul
| play at Gmail, both statements have equal strength.
| cstrahan wrote:
| > [...] if you don't understand that a DKIM-signed message
| proves the mailhost was authorized, and at least some of the
| headers could easily prove who sent the message.
|
| I'd love to hear more about this. If I send an email from the
| Gmail UI, at a high level, how does DKIM ensure that Google
| _can't_ deliver the message with a different FROM header?
|
| And, to clarify: your answer can't involve trust/reputation
| because, well, both you and the person you quoted chose to
| use the word "prove". Something being inadvisable and
| unlikely (Google forging emails) does not prove the opposite
| thereof.
| rainsford wrote:
| Proving something always comes with assumptions and
| caveats. Even if we're talking about proving something
| cryptographically, the underlying assumption is that crypto
| primitives are unbroken or that participants retain control
| of their keys.
|
| In this context, DKIM definitely proves a user sent an
| email if you're willing to accept the assumption that the
| email provider is not arbitrarily sending emails that users
| did not write. This is perhaps not as strong a proof as if
| there were user specific (and user controlled) signing
| keys, although even then you're still making assumptions
| about the user's ability to control their keys, the
| software involved, etc. In the case of DKIM, it's certainly
| a much stronger proof that the user did indeed send an
| email than if you did not have the DKIM signature.
| cstrahan wrote:
| > Proving something always comes with assumptions and
| caveats. Even if we're talking about proving something
| cryptographically, the underlying assumption is that
| crypto primitives are unbroken or that participants
| retain control of their keys.
|
| Absolutely. Propositions have a premise and a conclusion.
| In regular conversation, it is usually safe to omit part
| of the premise when it is assumed that everyone is on the
| same page, otherwise communication would be overly
| laborious. I agree 100%. An example in my response: I
| said nothing of the assumption that the cryptography in
| use hasn't been broken through quantum computing or other
| means as I think it's pretty obvious that, if
| verification of authorship hinges on the cryptography
| functioning as intended, it should be apparent that "the
| cryptography hasn't been broken" should be part of the
| premise. Communication would be practically impossible if
| we all have to add in an infinity other ground truths,
| like "the brains of humans of earth haven't been taken
| over by extraterrestrial parasites", or "we're _not_
| talking about a point in time before humans came into
| existence ", or whatever.
|
| > In this context, DKIM definitely proves a user sent an
| email if you're willing to accept the assumption that the
| email provider is not arbitrarily sending emails that
| users did not write.
|
| I was waiting for this comment.
|
| I'll restate your proposition, to make it more explicit:
|
| "If an email provider won't arbitrarily send emails that
| users did not write, then a valid DKIM signature for a
| given email entails that the author as indicated in the
| FROM header was indeed the actual person/entity that
| wrote the email."
|
| And that's fine!
|
| So, if we take the premise to be true (as it seems you
| do), _then_ we arrive at "a valid DKIM signature for a
| given email implies that the author as indicated in the
| FROM header was indeed the actual person/entity that
| wrote the email". Great!
|
| However, to clarify why I wrote my original comment,
| here's the important bit from the OP:
|
| > A DKIM signature does not prove that an individual sent
| the email, the key is not personal. A DKIM signature
| proves that the sending service is a delegated sender for
| the domain. Meaning that a correct DKIM signature proves
| that the part after the '@' symbol in the sender address
| is authentic. Not the part before that. If you want to
| use a personal signature, you can use S/MIME.
|
| There's nothing about this that suggests that this
| commenter would find the earlier proposition invalid.
| More than that, if we are charitable (as we should be, if
| we want civil, productive discussion) and assume that
| they actually do consult in this space, there is no
| reason for us to assume that they don't already hold this
| proposition to be valid.
|
| What the original commenter wrote could be restated as:
|
| "If an email provider is _not_ trusted to _not_ send
| arbitrary emails, then DKIM is _not_ sufficient proof to
| trust that the supposed sender actually authored the
| email -- it is _only_ sufficient proof to trust that the
| email was delivered via the respective email service. "
|
| Looking at your response to the original commenter:
|
| > You are technically correct (the best kind of correct),
| but in practice the nuance you're referring to does not
| make as much difference as you think. Yes, email senders
| could send email from whatever user they want or change
| the body from what the user wrote, but in practice of
| course they aren't doing that for the kind of email
| providers like Gmail that most people use.
|
| Okay. Sure. _You_ trust Gmail or whoever. That doesn 't
| invalidate the second proposition -- that just means that
| (under your world view) it is _not satisfiable_.
|
| Ultimately, what I was initially responding to:
|
| > You should probably stop "consulting on email security"
| if you don't understand that a DKIM-signed message proves
| the mailhost was authorized, and at least some of the
| headers could easily prove who sent the message.
|
| comes off as uncharitable at best, and undeservedly
| antagonistic and offensive at worst. Your response thus
| far hasn't provided a valid counterpoint.
|
| And, to be clear, I actually _disagree_ with the original
| commenters assertion:
|
| > So the proposed scheme would only work in a situation
| where you are owner of the DKIM key (thus in practice
| where you are the owner of the host sending the email),
| and where you also own the domain. It is trivial for a
| prosecutor to prove the owner of the domain, or the owner
| of the host that used the DKIM key. No amount of
| publishing keys will help you deny that ownership.
|
| (edit: TBC, I think this statement is true but doesn't
| effectively refute the utility of publishing the keys --
| that, if everyone has the old key, the signatures of old
| emails become useless, while the signature of a new email
| can still be used to check authenticity... that
| authenticity, of course, being predicated on the
| assumption that Gmail or whoever isn't sending fraudulent
| emails, which admittedly is a pretty safe bet)
|
| But that's _orthogonal_ to what this sub-thread is
| discussing (whether second proposition above is valid),
| which started with someone snarkily implying that someone
| else is incompetent in their field.
| salawat wrote:
| OpenDKIM allows you to setup signing tables which can include
| individual keys for individual sending addresses.
|
| So you're kinda right in the sense it's mostly authenticating
| the sending service's configuration and relationship to the
| domain, but kind of wrong on the front where the part before
| the @ isn't fundamentally authenticated. It is.
|
| The User/User-Agent decoupling issue is still omnipresent, and
| adds a fundamental layer of uncertainty, that you are correct
| in. The fact we still seemingly need to grind that in to the
| uninitiated at times feels like there needs to be a cure to
| magical thinking formulated more than anything else.
| BoppreH wrote:
| I think this is missing the trust that the delegated sender
| adds. If you have an email with a DKIM signature from Gmail,
| then either:
|
| a. The email is authentic.
|
| b. Gmail has risked its reputation to "forge" the signature of
| an email it never sent.
|
| That's strong evidence that the email is authentic! On the
| other hand, if Gmail were to publish their old DKIM keys,
| _anyone_ with technical skills could have forged that
| signature.
|
| As for why repudiation is desirable for emails, think
| protesters. They want to verify that the emails they receive
| are really from each other, but minimize their exposure in case
| the emails leak.
|
| It's a common property for secure messaging systems, and I
| don't see why emails shouldn't have it too.
| michaelmrose wrote:
| Remember when Hans Reiser successfully destroyed all
| definitive forensic evidence of his murder of his ex and then
| got convicted anyway because nobody believed he was innocent
| then traded handing over her body for a lighter sentence?
|
| Even if you could theoretically create a mathematically
| plausible doubt it doesn't matter if a judge and or jury
| doesn't believe it.
|
| Also both Google and the recipient can attest the message hit
| the server prior to the key being published. You MAY be in a
| position where your email provider is in a different
| jurisdiction and not inclined to cooperate but if bob the
| witness already gave up your message won't he give up the
| timeline breaking any hope of repudiation?
|
| So all hope of an upside is basically a pipe dream. Lets talk
| about the downside you can now sign crap with Googles already
| published key and lie about the timeline. You can have
| "experts" go on TV and lie about authentication. Since most
| people know less than nothing on the topic it sounds on its
| face believable.
| pseudalopex wrote:
| Hans Reiser was convicted because there was much
| circumstantial evidence, he insisted to testify, his
| explanations were unlikely, and jurors thought he acted
| guilty. He said he threw away his car's passenger seat
| after his ex wife disappeared so he could sleep in the car.
| And removed the rear carpet to make a futon. But threw it
| away. And so on.
|
| Criminal cases are not the only scenarios when
| authentication is relevant. Most email providers would not
| authenticate a message without a court order probably. And
| they may or may not retain sufficient information. A
| recipient whose messages were hacked would not want to
| authenticate the messages usually. A recipient who would
| benefit from disclosing a message the sender didn't want
| disclosed would benefit from forging a message usually.
|
| Is it now not possible for people to go on TV and lie to
| people who know less than nothing about a topic?
| zajio1am wrote:
| Well, there is also third option: the sender account was
| compromised.
|
| But yes, it is still pretty strong evidence.
| chias wrote:
| I don't think that's an accurate characterization. If you
| have an email with a DKIM signature, from Gmail or from a
| myriad of vendors, then either:
|
| a. The email is authentic.
|
| b. The service allows whoever administers the service to
| configure outgoing emails however they please.
|
| c. There is a documented method by which the service allows
| you to override the sender address.
|
| d. The service has risked its reputation to "forge" the
| signature.
|
| The middle two options are extremely common in any business
| setting. Gmail supports both.
|
| --
|
| I am assuming, since your post does not appear to be agreeing
| with the parent comment, that when you say "authentic" you
| mean "sent or authorized by the individual named in the
| username field". If you mean "sent in a manner configured by
| some entity with authority on how the domain is used for
| sending email", then that is exactly the parent comment's
| point.
| klausa wrote:
| >It's a common property for secure messaging systems, and I
| don't see why emails shouldn't have it too.
|
| Because emails, fundamentally, are not, and cannot be, a
| secure messaging systems.
| zahllos wrote:
| > That's strong evidence that the email is authentic!
|
| So I run my own email server for family (mostly) but a couple
| of friends. As the GP points out, the DKIM keys do not
| identify the user and in particular I can produce a validly
| signed email for any user of any of the domains my server
| hosts. Only CMS oblique S/MIME would provide non-repudiation
| in the cryptographic sense, and only meet e.g. eIDAS
| requirements if stored on a hardware token (i.e. in the EU,
| if I sign a PDF with the USB token I have, it is a "qualified
| signature" and it can be interpreted as legally binding).
|
| On the other hand, there's a question as to what extent
| courts would understand the distinction between a valid and
| invalid/no DKIM signature. I guess what I'm saying is if it
| came down to a contractual dispute, "strong evidence" would
| not be good enough. If it came down to "this person organised
| a protest and that's a crime" I think even invalid DKIM would
| be fine. From what I've seen of court proceedings, mostly
| stuff shared here and so US stuff and not my native
| jurisdiction, but I have yet to see anyone cast doubt on an
| email's provenance based on DKIM. I'm going to go out on a
| limb and say in strongly democratic jurisdictions an email
| recovered from a server in someone else's inbox will likely
| be treated as valid unless there is something like an unusual
| sender IP to cast doubt on it. So "strong evidence of
| authenticity" probably won't come from DKIM.
|
| In jurisdictions where protesting means you disappear, I
| doubt "check the DKIM keys!!!" is going to help - at least in
| part the police/courts might not be so worried about whether
| you are guilty or not.
|
| Agree completely with the sibling comment that e-mail isn't
| suitable for secure messaging.
| proto_lambda wrote:
| > It is trivial for a prosecutor to prove the owner of the
| domain, or the owner of the host that used the DKIM key
|
| The point of publishing the keys is that _anyone_ can then sign
| messages, making "ownership of the domain" a meaningless
| factor, no matter how much you can prove it.
| djbusby wrote:
| Sounds like spammer could use the key then too? Send DKIM
| signed message from my domain?
| proto_lambda wrote:
| By the time you publish the key, it is no longer in your
| DNS records and thus no longer trusted by any receiving
| mail server.
| LeonM wrote:
| There lies the problem IMO.
|
| The publication date of the DKIM record will be _after_
| the email has been sent.
|
| Obviously there is no real way to 'prove' the publication
| date of a DNS record, other than asking the DNS service
| provider for the logs maybe.
|
| So IANAL, but I'd say the lack of provability of the
| publication date of the key makes it unsuitable for
| deniability. Just because the DKIM public key is
| currently public, does not prove in any way that it was
| already public when the email was sent.
| nulbyte wrote:
| > The publication date of the DKIM record will be _after_
| the email has been sent.
|
| Was that email even sent? Maybe it was forged after the
| key was leaked. This is what the author of the article is
| pointing out: The old private key being public, you can
| no longer rely on DKIM alone to prove anything about a
| document with a signature created with that key.
| A1kmm wrote:
| Deniability means an adversary can't prove you did X, not
| that you can prove you didn't do X.
|
| So to check if the property holds, the question is not:
| can you prove the key was public when the email was sent,
| it is a) can the adversary prove when the email was sent,
| and b) can the adversary prove that the key was not
| public at that timestamp?
|
| On a), the adversary cannot just rely on Date: headers if
| those headers are signed by a public key, and the private
| key is now public - someone faking an email could just
| back-date the Date header to a date when the private key
| was not available, and hence an argument by the adversary
| that 'the Date header says it was sent at timestamp TS1,
| and at TS1, the key wasn't public, so therefore the email
| can't be repudiated' is not sound.
|
| If the recipient of the email cooperates (or anyone who
| gets access to the email before the private key is
| published), they could, for example, hash all their
| emails, and then hash the list of hashes on a regular
| basis, and put that hash in a busy public blockchain.
| That would provide an upper bound on the email send
| timestamp, and, combined with a well-defined private key
| publication timeframe, provide non-repudiation.
| maxerickson wrote:
| The point isn't establishing deniability, the point is
| undermining the authenticity argument (these are at least
| subtly different I think).
|
| It isn't actually possible to prove that the key was
| secure at some point in time prior to publication,
| publication of the key moots that discussion, which is
| probably going to generally be socially favorable enough
| of the time to be the better thing to do.
| EdiX wrote:
| This whole meme started because people could use DKIM to verify
| that Hunter Biden really did send his incriminating emails while
| we were all supposed to think they were russian disinfo.
|
| Some people are literally so politics poisoned that they can't
| see that it cuts both ways. I can't wait until DKIM is used to
| prove something bad about Trump so everyone can flip their
| position on DKIM.
|
| It isn't going to change anything, politics poisoned brains won't
| see the irony. But it's always funny to see anyway.
| remram wrote:
| The point is that it allows something it is not designed for. I
| don't think anyone is against it because it hurt their
| political party, the cat is out of the bag on that front
| anyway.
| pseudalopex wrote:
| Politics poisoning is thinking no one has principles or own
| interests. Or noticed OTR, Signal, Telegram in 10 or 20 years.
| tkfu wrote:
| I have a big soft spot in my heart for idealistic crypto stuff
| like this. Everything the author argues is true...but there's no
| way in hell commercial email providers would actually publish
| their private keys. The only way it would be in their interest to
| make it easy to forge old emails would be if a substantial
| portion of users demanded it, and that's never going to happen.
| sylware wrote:
| SPF is enough (and it is built-in with plain no-DNS SMTP
| servers).
| tamimio wrote:
| It's not, SPF won't survive a forwarded email. Make sure to use
| DKIM and DMARC policy to properly mitigate any authenticity
| issues.
| 0x073 wrote:
| Works great with email address forwarding.
| pawal wrote:
| Not if you want to deliver e-mail to Google, they recently
| added this as a requirement.
| sirius87 wrote:
| Yep. I have a catch-all email address for a domain that
| forwards all mail to Gmail and that stopped working somewhere
| in the Jul-Aug timeframe.
|
| Had to set up DomainKeys to fix the issue.
| sylware wrote:
| Still working fine here. And about to switch to no-DNS emails
| (alice@[x.x.x.x] and bob@[IPv6:...] in the SMTP specs)
| Avamander wrote:
| Highly unlikely you'd be able to deliver any mail to any
| significant operator after that switch.
| sylware wrote:
| I did run a few months in no-DNS email mode without
| issues, but was 2-3 years ago. I know regulation and
| lawyers may be needed if significant conflicts happen
| with unreasonable system administrators.
|
| It is critically important to keep the emails flowing
| independently from the DNS mafia/racket, like the web,
| but I guess we all very know that here on HN.
| Avamander wrote:
| > It is critically important to keep the emails flowing
| independently from the DNS mafia/racket
|
| It's really not a racket and it's really not critical.
| sylware wrote:
| > It's really not a racket and it's really not critical.
|
| This means, we cannot agree.
| tmpX7dMeXU wrote:
| Certainly not.
| Avamander wrote:
| SPF is so obsolete that DMARC is going to get an option to
| disable evaluating it altogether.
| alt227 wrote:
| Why do you say SPF is obsolete? What has replaced it?
| Avamander wrote:
| DKIM is in all aspects better.
| donatj wrote:
| I don't think this is as cut and dry as the author would have you
| believe.
|
| Given the options, I think I would rather have the class of
| problems that come with being able to prove where an email
| originated instead of the problems that arise from _not_ being
| able to do so.
|
| Proof protects a lot of innocents from bad actors in a lot of
| ways. Lack thereof protects whistleblowers and the like. It's not
| a totally clear win one way or the other. I just suspect the
| prior helps more people.
| remram wrote:
| This deficiency just makes email a worse mechanism overall.
| Repudiable channels still exist, they are just not email. Why
| not fix email?
| ocrow wrote:
| A global database of which DKIM keys were served by which mail
| domains on which day would not be hard for anyone to create and
| would make it possible to cryptographically validate the sending
| host after the fact, even for hosts that rotated and published
| old DKIM key pairs, surely? This technique to make old emails
| repudiable doesn't seem very robust.
| gumby wrote:
| That would make the system even easier.
|
| The point of this proposal is that with rotation someone could
| not prove that a message hadn't been forged retrospectively. It
| would then be almost impossible to establish an airtight chain
| of custody
| remram wrote:
| That does not break the scheme at all? In fact it is counting
| on it. The point is to publish the private keys, which would
| match the public keys in your database.
|
| The point is to forge emails, not domain keys.
| time4tea wrote:
| My previous comment was flagged, but I'm happy to restate.
|
| The author doesn't understand what repudiate means, and therefore
| all the arguments are nonsensical.
|
| To repudiate means, according to Cambridge dictionary "to refuse
| to accept something or someone as true, good, or reasonable"
|
| So, when a transaction or email is repudiated, it means that
| someone is claiming that they didn't do it, despite the fact that
| it was done.
|
| Non-repudiation is a characteristic of a system whereby a user of
| the system will find it difficult or "impossible" to repudiate
| that they did an action in that system.
|
| So when the author claims in a title that "Non-repudiation of
| emails is undesirable" they are getting the words and meaning
| mixed up.
|
| It is repudiation that is undesirable, and that's why non-
| repudiation is such an important characteristic of some types of
| system.
| phyzome wrote:
| Sorry, this is incorrect. Non-repudiation is undesirable _for
| email senders_. It is desirable in some other systems, such as
| notarization and the signing of contracts.
| tjoff wrote:
| _If this is not done, your emails are "non-repudiable", meaning
| that if they are leaked, anyone (eg, journalists, haters) can
| verify that they are authentic, and prove that to others. This is
| not desirable (for you)._
|
| Not convinced, the bigger problem today seems to be that someone
| claims that you sent something you didn't and if you do the above
| you can't disprove that.
|
| You could sign your emails, but then the whole point of
| publishing the private keys is negated anyway...
| gorgoiler wrote:
| Double DKIM?
|
| The first signature for your future proof-of-authorship needs
| and the second for regular DKIM mechanisms to accept your
| email?
|
| The first key isn't ever published but you keep it if you need
| to prove your email was written by you.
|
| The second key is rotated regularly with the private key
| published so that always have the ability to claim "I didn't
| write that".
| A1kmm wrote:
| But then you could just have a third key to use in place of
| the first for anything you think you might want to get out of
| later.
|
| You could have a mechanism to prove two emails are signed
| with the same key, without revealing the public key (e.g.
| using a zero-knowledge technique like zk-SNARKs) - but that
| might then be functionally equivalent to just revealing the
| key in terms of non-repudiation anyway.
| remram wrote:
| The comment above asked for a way to prove it was _not_
| written by you.
| nulbyte wrote:
| > You could sign your emails, but then the whole point of
| publishing the private keys is negated anyway...
|
| Not really. The point is to deliver emails. Once it's
| delivered, it doesn't matter as much.
| tjoff wrote:
| _... of publishing the private keys ..._
| handsclean wrote:
| Here's the thing about deniability: even if you successfully
| remove all cryptographic proof of provenance, actually denying it
| is still asserting a frame job. That's useless if the party
| you're trying to mislead either is or trusts the data source,
| like, say, in the case of police surveillance, hackers, nation-
| state attackers...
|
| I think the real solution to future breaches is ephemerality,
| which is why it's critical for any secure messaging service to
| not only implement all-participant auto-delete, but to also make
| it easy to opt in to only for specific messages, since that
| brings the cost:benefit down to a point that it's actually used.
| JoBrad wrote:
| The frame job is not a stretch. I've seen spear phishing
| campaigns that spanned weeks to convince someone that's request
| to transfer money, at the very end, was legit. Some of the
| intermediate emails were pretty innocuous.
| handsclean wrote:
| That's just impersonation, framing is when it's about how you
| make the real party look, not yourself. Which would be weird,
| not implausible, but you get to implausible when you assert
| not just that somebody framed you, but that you were framed
| by some specific trusted party like the police or Google, and
| also you have zero evidence.
| matthewdgreen wrote:
| People fake emails all the time: see examples in this comment
| thread. Literally all it takes is a text editor. This is not
| the same thing as a criminal frame job, where someone is going
| to put your fingerprints on a knife at a bloody crime scene.
| talent_deprived wrote:
| "You should be rotating the key regularly and automatically, and
| publishing old private keys."
|
| OK, I read the article, I operate my own email server and nothing
| I read convinces me I should do what they're suggesting.
___________________________________________________________________
(page generated 2023-10-01 23:00 UTC)