On Sat, 11 Dec 2021, Sebastian Nielsen via mailop wrote:
I just got a new idea for a new internet standard - that builds upon DKIM -
that should be named as DKIM-QR.
And want to hear your toughts about the idea.
I am not interested, even though my current mail client does not
calcuate or report results of DKIM tests.
The idea is as follows:
An DKIM-compliant sender, can choose to include a QR-code in the email, as a
picture. How this QR-code is generated on the sender's side (either by
unique ID that loads the whole QR from a database, or by embedding the whole
DKIM signature inside the src= of the image and then have server to generate
the QR, or simply attaching the QR code to the email as a inline attachment)
is up to the sender.
The QR code's textual content should be "dkim://" followed by the content of
the "DKIM-Signature:" header field, in an URL_Safe format, then followed by
the content of the fields being signed in the same order as it appears in
the h= field.
Note here, that if full body is signed, the content of the QR code
signature, and the DKIM-Signature: field, will differ by the bh=, as the
email without QR-code embedded will be signed in the QR-signature, and the
header DKIM-Signature will have the email WITH the QR-signature. This should
be completely valid, otherwise a chicken&egg problem would appear if the
signature must be a signature of itself.
As you explained in a private reply, this means that DKIM-QR does not
signed the body of the message.
That and having to take a picture with my phone kill the idea for me.
If the sender want to save on signing resources, he can use the l= tag to
exclude the to-be-appended QR from body validation, then the sender can just
copy the mail's signature from the header and append the generated QR to the
email.
And now to why this would be useful:
An receiver of an email, could then scan the QR code with his mobile phone,
and the mobile app would do the validation against public DNS. This, if this
would become a standard, could be even implemented built-in in phones.
The validation popup should be part of phone, not a web page, indicate if
signature validation is OK, which domain that signed (d= of the DKIM
signature), and the content of the fields "From", "To", "Date", "Subject" -
if those fields were signed.
This allows a user, to be able to DKIM validate an email EVEN if the
receiving system has no support for DKIM validation at all, neither the
client or receiving mail server. This would increase trust for email, as
users that suspect an email with an embedded link is phishing, could easily
scan the QR code with his mobile phone, and instantly know the email is
legit.
Security considerations:
If a phisher steals the QR code, he would not be able to use it, because the
Date: will be different. It would be immediately clear to the receiver that
its an old signature that have been wrongly reused.
I get spam with old dates.
DKIM signatures roll-over, so you cannot verify a message you received a
year ago.
Since the To: is included in the validation popup, it would also be evident
to the original user that the To: address doesn't match.
And misusing a QR for one email, to send a phishing email with another
content, would also be evident either by the subject tag not matching the
content of the email, or the subject tag not matching whats shown in
validation popup.
So the user has to compare the pop-up with what appears in the mail-client ?
If they actually read and understood what was in the mail client they
would significantly reduce the risks.
DMARC and gmail (and probably most other large mail providers) accept mail
if *either* of SPF and DKIM pass, so I imagine that a significant amount
of legitimate email fails DKIM, making the app give many false warnings.
There is a risk that someone might include a malicious link instead of
dkim:// in QR-code, but since all the QR scanner apps today ask the user if
they want to open the link, the danger decreases.
Also another thing is that mobile phones are today inherently more secure,
as they, unless configured, will refuse to install binaries from unknown
sources and isolate apps from each other, meaning that even if a dangerous
link would be mistakenly opened, nothing would install without clicking
through multiple consent windows.
This would bring DKIM more to the masses, by senders being able to put in a
"Scan-To-Verify" DKIM-QR in emails, also prompting users to verify their
emails.
As others have said, many people read email on their phone ...
--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
