On 2021-12-14 at 02:30:11 UTC-0500 (Tue, 14 Dec 2021 08:30:11 +0100)
Sebastian Nielsen via mailop <sebast...@sebbe.eu>
is rumored to have said:
Note that to validate the message, the app needs access to not only
the signed header fields, but also the body, that the value of bh=
is based upon.
Of course. That’s why I suggested that content validation should be
ignored. Only headers should be validated.
Since the content is "signed" using bh= hash, the hash can be ignored
and everything else can be validated.
A hash is not a signature. The bh field is used instead of the actual
canonicalized body to make signing and verifying easier. Hashing is MUCH
cheaper than RSA-signing.
Please explain in simple terms why you believe that the verifier does
not need access to the body, when what it is verifying DEMANDS that the
verifier hash the body to check the validity of the bh value. What stops
a bad actor from scooping out the original content of a valid message
and replacing it with whatever body they want, preserving headers and
the QR code?
This of course puts some responsibility on the user that is scanning
the QR code, to ensure the details (from, to, date, subject) matches
up with the email they are seeing on the screen, and that "date" is
not too far in the past, so the QR code is not stolen from a
legitimate email.
Are you aware of the fact that a lot of modern MUAs hide the real email
addresses in headers? That's why spammers do this:
From: Your Friend goodguy@bigdomain <badguy@fastflux>
Users frequently can't see any actual email addresses in headers without
a click or three.
Since the To: header field is included in DKIM and QR code, it would
mean a fraudster somehow needs to be able to gain access to the
victim's mailbox to be able to mint a email that matches a QR code.
The idea here is that a end-user should be able to scan'n'verify a
email by QR-code and not have to worry about phishing. Since the
details about who signed the email and the data in email comes out in
clear, it will be very evident if a emai from a bank is signed by
"russianwebhost.ru" or similar and thus alert the user about phishing.
Yes, but if it is signed by nore...@paypa1.com and claims to be from
PayPal, it will be evident to software and those of us with InfoSec
Paranoia Syndrome, while most users never notice the difference.
can implement new standards
Its about excluding the client and the receiving server from the
equation. If anyone - regardless of email operator or receiving server
or client - can download a app and scan a QR code to ensure an email
is not phishing, I think it gets traction, especially since the QR
code would be visible in email, people would look up "Why does all
email from Paypal now include a QR code" and they find out about the
verification.
Without verification that the bh value is actually the body's hash, the
whole thing is useless. No one cares about verifying a pile of headers
without involving the body.
Are there still so many MUAs with no DKIM add-on?
MUAs need to include it per default for it to get traction.
DKIM is not designed for MUA deployment. There is so much random damage
casually done at delivery time by MDAs that invalid signatures are
frequently the rule rather than the exception in delivered messages. For
example, Sendmail's stock This is getting worse, not better, as many
systems are adopting the disappointing habit of marking up all
"external" mail in highly user-visible ways, specifically to alert users
to the possibility of phishing.
Ultimately, this whole discussion is meaningless without a real
specification (examples ARE NOT a specification) and a base
implementation. I believe that your fundamental design is fatally flawed
at its core but it could easily be that you are thinking of something
that I am not understanding from what you've written.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
