Re: [mailop] Idea for new internet standard: DKIM-QR

[Alexey Shpakovsky via mailop]

Thanks Brandon for your message,

I forwarded it to my DKIM-lacking friend, he sent me some screenshots, but
I wasn't able to find any way to see DKIM signatures in them (there were
no "More" button or menu item visible anywhere).

If you want to investigate it further, feel free to contact me off-list.

Worth mentioning that I also wasn't able to see DKIM headers or auth
results on my own Android phone in Samsung Mail app. So it can be either
me, or a different example of an application which doesn't show this
information.

As for the fact that DKIM isn't a well known concept for 99.99% of users -
I totally agree with you here, probably one needs to be mailop (or run
their own mail server) with relatively recent experience (wiki says it was
defined in 2011) to know what it means. Even those who were self-hosting
email but stopped 15~20 years ago might've never heard about it.

Aleksei.



On Mon, December 13, 2021 19:54, Brandon Long wrote:
> The Android Gmail app does show if a message is DKIM signed, in about the
> same way as the web app does... and I assume the iOS version does as well.
>
> On the web, click the down arrow next to the to, it'll show you "more"
> headers, including 'signed-by" if it has a valid signature with the domain
> of the signature.
>
> On Android, there's an extra click, down arrow for "more" headers than
> "view security details" to see the signed-by... not sure why the extra
> click.
>
> As for "why doesn't it show it much more prominently"... well,
> signature/DKIM isn't a well known concept for 99.99% of users, and being
> signed by "someone" isn't really indicative of much.
> It's either signed by someone you recognize, or it's really just a signal
> for the antispam/antiphishing systems.
>
> Brandon
>
>
> On Mon, Dec 13, 2021 at 9:37 AM Alexey Shpakovsky via mailop <
> mailop@mailop.org> wrote:
>
>> On Mon, December 13, 2021 17:56, Alessandro Vesely via mailop wrote:
>> > Are there still so many MUAs
>> > with no DKIM add-on?  Or is it because people is not free to install
>> them?
>>
>> Maybe they don't prioritize DKIM over other MUA features. Personally I
>> have a friend who uses Gmail on his phone, which doesn't show him DKIM
>> verification results (although Gmail server adds a relevant header), so
>> he
>> asks everyone to send S/MIME-signed messages to him.
>>


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Idea for new internet standard: DKIM-QR

[Larry M. Smith via mailop]

On 12/11/2021, Sebastian Nielsen via mailop wrote:

Hi.


(snip)
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 problem would 
appear if the signature must be a signature of itself.




On principal I do not like anything that modifies a message body or most 
of the MUA (mail user agent) provided headers in flight.  The sender or 
the receiver can modify these to suit their needs, but not any other 
systems.  Sender or receiver can be a business entity or an individual 
user; to my mind the test I would use is who "owns" the mailbox. 
Employees of a business entity do not own the mailbox, the business does.


(snip)
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.


It sounds like you want sweeping changes to MUAs to support this, and I 
feel that it would be easier to get MUAs to support the already existing 
DKIM and DMARC standards, even easier would be to find a mailbox 
provider that will do this for you.  Attempting to get phone MUAs to 
support something like this DKIM-QR, when I have yet to find one that 
supports IMAP subscriptions, is umm... Going to be hard.


Having said that, I do not know how much unwanted mail is stopped by 
DMARC mis-alignment...  I simply do not have stats.  I do suspect that 
most of the traffic such systems would catch would be bot-generated 
email, and not much else.  Most of the phishing that I do see is from 
dedicated spammers willing to pay for both domains and IP addresses; 
stolen user accounts; and free-mail providers with poor outbound abuse 
handling -- I'm looking at you Gmail.  DKIM/DMARC isn't going to solve that.




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.


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.


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.


Would love to hear the toughts about the idea.


The last issue that I have here is the use case for users, and just how 
many of them you would expect to find the feature useful.  It seems to 
me that the vast majority of email's user base just doesn't care, 
doesn't want to go though extra effort, and/or believes that this is 
something that mailbox provider should be doing for them for them.



--
SgtChains

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Idea for new internet standard: DKIM-QR

[Bill Cole via mailop]

On 2021-12-14 at 02:30:11 UTC-0500 (Tue, 14 Dec 2021 08:30:11 +0100)
Sebastian Nielsen via mailop 
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 

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

Re: [mailop] Idea for new internet standard: DKIM-QR

[Jan-Pieter Cornet via mailop]

On 14-12-21 16:31, Sebastian Nielsen via mailop wrote:

The problem here is that the signer isn't shown prominently in MUA's.
Here is where the QR code comes in.


You do realize you're acting very similar to this, right? https://xkcd.com/927/

"current standards aren't being implemented, we must create a new standard".

If you ask me, BIMI is a better way forward that's understandable for 
end-users, and offers something tangible for domain owners for their mail 
authentication efforts (although the verified logo bit is still not completely 
solved - this isn't a FUSSP either, but I believe it's a step in the right 
direction).

Problems with Sweden's KYC are best addressed with a clue-by-four applied to 
the hea... um, I mean, by gently educating the mail admins that they should not 
promote phish by having their users click on links in email that takes them to 
a form where they should input PII.

--
Jan-Pieter Cornet 
"Any sufficiently advanced incompetence is indistinguishable from malice."
- Grey's Law



OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Idea for new internet standard: DKIM-QR

[Tobias Herkula via mailop]

Hi Sebastian,

please also be aware of the fact that the people you want to target here, will 
most likely not recognize such an image as QR-Code at all, as the amount of 
data you want to put in it is quite large and needs a lot of error correction 
data to counter the moiré effect, as your use case is scanning the code from an 
active display. So, for most people it will look like an image of "white 
noise", as even the recognizable squares in the corners of a QR-code will be 
relatively small in comparison to the overall size of the image. 

We as GMX & Co, would also consider a DKIM Signature with l=0 as not acceptable.

Besides that, what John said...

/ Tobias Herkula (Web.de|GMX|Mail.com)

-Ursprüngliche Nachricht-
Von: mailop  Im Auftrag von Sebastian Nielsen via 
mailop
Gesendet: Dienstag, 14. Dezember 2021 16:32
An: 'Mailing List' 
Betreff: Re: [mailop] Idea for new internet standard: DKIM-QR

The problem here is that the signer isn't shown prominently in MUA's.
Here is where the QR code comes in.

So yes, a phisher might own a own domain, lets say spammydomain.xyz, and get 
the mail legitimately signed as spammydomain.xyz and get DMARC/DKIM pass.

That’s why I suggest this QR code scheme to make the signature more visible and 
prominent on the email (like a pen and paper signature on a snail-mail 
document) so when someone verifies the signature, it will be very prominent 
that spammydomain.xyz did sign the mail and not yourbank.com.

Gmail already has a user interface to show SPF and DKIM signatures, by pressing 
the little down arrow on "To: me".

That’s whats DKIM really lacking - authentication. Just that the email is 
signed isn't enough. It should be signed by the person that you are expecting 
to send the email, in this case yourbank.com And if some sort of authentication 
is added, it would practically be impossible to create a email that shows up as 
signed by "yourbank.com".


-Ursprungligt meddelande-
Från: John Levine via mailop 
Skickat: den 14 december 2021 15:53
Till: mailop@mailop.org
Kopia: thomasm-mai...@wupper.com
Ämne: Re: [mailop] Idea for new internet standard: DKIM-QR

It appears that Thomas Mechtersheimer via mailop  
said:
>for DKIM/DMARC checking in MUAs and prominently displaying these 
>authentication results, which would get the same level of securtiy with 
>already existing standards.

Please keep in mind that level of security is "none".  People who send phishes 
know how to add DKIM signatures and get DMARC alignment.  They are often better 
at it than some legit senders.

DKIM and DMARC are useful but only as part of an overall mail filtering scheme, 
not as FUSSPs.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Idea for new internet standard: DKIM-QR

[Brandon Long via mailop]

The Android Gmail app does show if a message is DKIM signed, in about the
same way as the web app does... and I assume the iOS version does as well.

On the web, click the down arrow next to the to, it'll show you "more"
headers, including 'signed-by" if it has a valid signature with the domain
of the signature.

On Android, there's an extra click, down arrow for "more" headers than
"view security details" to see the signed-by... not sure why the extra
click.

As for "why doesn't it show it much more prominently"... well,
signature/DKIM isn't a well known concept for 99.99% of users, and being
signed by "someone" isn't really indicative of much.
It's either signed by someone you recognize, or it's really just a signal
for the antispam/antiphishing systems.

Brandon


On Mon, Dec 13, 2021 at 9:37 AM Alexey Shpakovsky via mailop <
mailop@mailop.org> wrote:

> On Mon, December 13, 2021 17:56, Alessandro Vesely via mailop wrote:
> > Are there still so many MUAs
> > with no DKIM add-on?  Or is it because people is not free to install
> them?
>
> Maybe they don't prioritize DKIM over other MUA features. Personally I
> have a friend who uses Gmail on his phone, which doesn't show him DKIM
> verification results (although Gmail server adds a relevant header), so he
> asks everyone to send S/MIME-signed messages to him.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Idea for new internet standard: DKIM-QR

[Sebastian Nielsen via mailop]

The problem here is that the signer isn't shown prominently in MUA's.
Here is where the QR code comes in.

So yes, a phisher might own a own domain, lets say spammydomain.xyz, and get 
the mail legitimately signed as spammydomain.xyz and get DMARC/DKIM pass.

That’s why I suggest this QR code scheme to make the signature more visible and 
prominent on the email (like a pen and paper signature on a snail-mail 
document) so when someone verifies the signature, it will be very prominent 
that spammydomain.xyz did sign the mail and not yourbank.com.

Gmail already has a user interface to show SPF and DKIM signatures, by pressing 
the little down arrow on "To: me".

That’s whats DKIM really lacking - authentication. Just that the email is 
signed isn't enough. It should be signed by the person that you are expecting 
to send the email, in this case yourbank.com
And if some sort of authentication is added, it would practically be impossible 
to create a email that shows up as signed by "yourbank.com".


-Ursprungligt meddelande-
Från: John Levine via mailop  
Skickat: den 14 december 2021 15:53
Till: mailop@mailop.org
Kopia: thomasm-mai...@wupper.com
Ämne: Re: [mailop] Idea for new internet standard: DKIM-QR

It appears that Thomas Mechtersheimer via mailop  
said:
>for DKIM/DMARC checking in MUAs and prominently displaying these 
>authentication results, which would get the same level of securtiy with 
>already existing standards.

Please keep in mind that level of security is "none".  People who send phishes 
know how to add DKIM signatures and get DMARC alignment.  They are often better 
at it than some legit senders.

DKIM and DMARC are useful but only as part of an overall mail filtering scheme, 
not as FUSSPs.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Idea for new internet standard: DKIM-QR

[John Levine via mailop]

It appears that Thomas Mechtersheimer via mailop  
said:
>for DKIM/DMARC checking in MUAs and prominently displaying these
>authentication results, which would get the same level of securtiy with
>already existing standards.

Please keep in mind that level of security is "none".  People who send phishes
know how to add DKIM signatures and get DMARC alignment.  They are often
better at it than some legit senders.

DKIM and DMARC are useful but only as part of an overall mail filtering
scheme, not as FUSSPs.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Idea for new internet standard: DKIM-QR

[Sebastian Nielsen via mailop]

No. The QR code should be added to mail body by the sender. Did you even read 
the original email with the idea?
If this becomes widespread like normal DKIM it will invite to verification.

-Ursprungligt meddelande-
Från: Thomas Mechtersheimer via mailop  
Skickat: den 14 december 2021 11:22
Till: Sebastian Nielsen via mailop 
Ämne: Re: [mailop] Idea for new internet standard: DKIM-QR

If the QR code is just another header added to the mail, you'll need support in 
every MUA to display this QR in a way that could be scanned easily.
Adding this to multiple MUAs is much more unlikely than adding support for 
DKIM/DMARC checking in MUAs and prominently displaying these authentication 
results, which would get the same level of securtiy with already existing 
standards.

--
Thomas Mechtersheimer - Necklenbroicher Str. 45a - D-40667 Meerbusch - Germany
EMail: thom...@wupper.com IRC-Nick: Mechti
  Of course I'm crazy, but that doesn't mean I'm wrong. I'm mad but not ill.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Idea for new internet standard: DKIM-QR

[Thomas Mechtersheimer via mailop]

If the QR code is just another header added to the mail, you'll need support
in every MUA to display this QR in a way that could be scanned easily.
Adding this to multiple MUAs is much more unlikely than adding support
for DKIM/DMARC checking in MUAs and prominently displaying these
authentication results, which would get the same level of securtiy with
already existing standards.

-- 
Thomas Mechtersheimer - Necklenbroicher Str. 45a - D-40667 Meerbusch - Germany
EMail: thom...@wupper.com IRC-Nick: Mechti
  Of course I'm crazy, but that doesn't mean I'm wrong. I'm mad but not ill.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Idea for new internet standard: DKIM-QR

[Jaroslaw Rafa via mailop]

Dnia 14.12.2021 o godz. 08:30:11 Sebastian Nielsen via mailop pisze:
> 
> 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.
[...]
> 
> Its about excluding the client and the receiving server from the equation.

I think you are missing a very important point.

If someone actually is so much aware of possible phishing that he/she is
willing to take extra steps (like scanning the QR code) to verify that the
email is not a phishing, then he/she has already taken these steps (for
example, checking the exact sender address, checking links in the message,
and before all, being very suspicious to all messages that are *unexpected*
- which is probably the most effective safeguard against phishing). For
these people, your idea is pretty much redundant, as they already check
their emails for possible phishing.

For those that are not aware enough, it is much better to teach them some
simple rules like "NEVER click on any links in an email message" - as for
example banks do to their customers - than to teach them about DKIM and
using some app to verify it. In my opinion it is too much to expect from
people that they will scan the code and compare details of the message
headers with what the app shows. It's too complicated, too much effort
needed.

And you still haven't addressed the case when someone receives their mail on
their phone. Do they need another phone to scan the QR code? And reading the
mail on the phone is just the case when one can easier fall a victim of a
phishing message than on a computer, because of obvious lacks of the phone's
UI. It's not so easy to check the real sender of the email, headers, links
etc. on a phone while you can quite easily do that on a computer. Currently
the majority of successful phishing attacks is via the phone. And more and
more often, these attacks use SMS messages rather than email. Email phishing
starts to become a bit "outdated", so I think it's a valid question, does it
have now any sense to invent a new methods of protection against email
phishing.

So my opinion is that your idea does not increase protection level against
phishing. It's mostly superfluous for "phishing-aware" users and when
reading mail on a computer, too complicated for "not-phishing-aware" users
and hard (if not impossible) to use when reading mail on a phone.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Idea for new internet standard: DKIM-QR

[Alessandro Vesely via mailop]

On Tue 14/Dec/2021 08:30:11 +0100 Sebastian Nielsen via mailop wrote:

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.

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.

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.



The risk, in that scenario, is due to the nature of email, which sends a 
message through various hops until it gets stored in the recipient's mailbox. 
Encryption between hops is not always granted, and, even if it were, messages 
are queued in clear text on all intermediate servers.  This provides for 
occasions to alter the text of the message.  For example, someone can modify 
just the payee account number in an invoice.  That fraud would be revealed 
checking bh=.



can implement new standards 


[...] people would look up "Why does all email from Paypal now include a QR 
code" and they find out about the verification.



Could a footer like "This message is DKIM signed" sort the same effect?



Are there still so many MUAs with no DKIM add-on?


MUAs need to include it per default for it to get traction.



Again, why is that so for MUAs but not for smartphone apps?


Best
Ale
--






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Idea for new internet standard: DKIM-QR

[Sebastian Nielsen via mailop]

>>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.

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.

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.

>> 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.

>>Are there still so many MUAs with no DKIM add-on?

MUAs need to include it per default for it to get traction.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Idea for new internet standard: DKIM-QR

[Alexey Shpakovsky via mailop]

On Mon, December 13, 2021 17:56, Alessandro Vesely via mailop wrote:
> Are there still so many MUAs
> with no DKIM add-on?  Or is it because people is not free to install them?

Maybe they don't prioritize DKIM over other MUA features. Personally I
have a friend who uses Gmail on his phone, which doesn't show him DKIM
verification results (although Gmail server adds a relevant header), so he
asks everyone to send S/MIME-signed messages to him.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Idea for new internet standard: DKIM-QR

[Alessandro Vesely via mailop]

On Sun 12/Dec/2021 00:33:12 +0100 Sebastian Nielsen via mailop wrote:


An user scanning such a QR code, would then look at phone screen, and then look 
on computer screen.



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.




I do agree that email clients should do DKIM validation, but getting every email client 
to do DKIM validation is a pretty tricky part. If the client software and receiving 
server can be left out of equation, then this could appear as apps in app-store where you 
easily can download a "DKIM-QR validator" like you can download a covidpass 
scanner from app store today, and if this gets traction enough, the feature would get 
implemented in phone's native cameras like Samsung has.



As a user of a Nokia 2760, I'm astonished and amused by this idea that 
smartphones apps (IPhone, Android, Pinephone, ...) can implement new standards 
more easily and faster than PCs (and servers).  Are there still so many MUAs 
with no DKIM add-on?  Or is it because people is not free to install them?



Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Idea for new internet standard: DKIM-QR

[Dave Crocker via mailop]

On 12/11/2021 3:33 PM, Sebastian Nielsen via mailop wrote:

The idea here was that it would be easier kind of, to create DKIM validation 
method, that only the sender and the sender's server need to be take part it, 
and then any user can validate the email, regardless of lack of support in the 
client or receiving server.



The premise appears to be that recipients are relevant to the effort at 
validating email.


They aren't.

Userful validation at scale is done by the incoming -- and sometimes 
outgoing -- filtering engine run by the email platform.



d/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Idea for new internet standard: DKIM-QR

[Andrew C Aitchison via mailop]

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 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

Re: [mailop] Idea for new internet standard: DKIM-QR

[Matthew V via mailop]

How do you scan the QR code when the majority of people use their phones 
to read the email?


Matt

On 2021-12-11 3:16 p.m., Sebastian Nielsen via mailop wrote:


Hi.

Im new here, and have been a mail server operator for quite a bit of a 
time.


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.

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 
problem would appear if the signature must be a signature of itself.


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.


URL-safe then means ; must be replaced with &, and all base64 strings 
should be converted to URL-safe format, where + is replaced by – and / 
is replaced by _, and any padding is removed.


On the end, a &-separated list of all signed header fields should be 
included after a ?.


The header DKIM-Signature: 
v=1;a=rsa-sha256;d=filmstaden.se;s=apsis;c=relaxed/relaxed; q=dns/txt; 
t=1639144767;h=content-type:mime-version:subject:date:message-id:to:from:feedback-id:reply-to:list-unsubscribe-post:list-unsubscribe;bh=2hkchgJnI3p6njCQxrjr8vXfERYte+YcbH+rnJbgtEs=;b=Ulh8/Hi1eYO4tp9TgSWVSsHvi2AE7bL48/lR+F5IcIwJufNbaGafOMjQvj7c8+w3mkWneNskNYHJ1WBr6T+cMaUPgmiUiRRviyl2BWhmPivcfZVA/B4xSOcRW2nMjOvWRldcrdkrz00g2XnwJwyyE02e8quaBjzODe4bTTUHWyNeap+kE9R0rAfTAcTvRYCOiqtUitIIU6a82W10C8rXR6Atx/wIl3mQAsP6sZpGckUtCfFPPdD1n6gCS6FDav7Ss7a2DQjzhkallSWaOfQ5IpKiYqcLf1kTPdtL4Gw/TYbKzOJDHCQ3BA8HBzFDXdhwBW03pkbuwzdz+T6/caylbg==


Would in QR-form become:

dkim://v=1=rsa-sha256=filmstaden.se=apsis=relaxed/relaxed=dns_txt=1639144767=content-type:mime-version:subject:date:message-id:to:from:feedback-id:reply-to:list-unsubscribe-post:list-unsubscribe=2hkchgJnI3p6njCQxrjr8vXfERYte-YcbH-rnJbgtEs==Ulh8_Hi1eYO4tp9TgSWVSsHvi2AE7bL48_lR-F5IcIwJufNbaGafOMjQvj7c8-w3mkWneNskNYHJ1WBr6T-cMaUPgmiUiRRviyl2BWhmPivcfZVA_B4xSOcRW2nMjOvWRldcrdkrz00g2XnwJwyyE02e8quaBjzODe4bTTUHWyNeap-kE9R0rAfTAcTvRYCOiqtUitIIU6a82W10C8rXR6Atx_wIl3mQAsP6sZpGckUtCfFPPdD1n6gCS6FDav7Ss7a2DQjzhkallSWaOfQ5IpKiYqcLf1kTPdtL4Gw_TYbKzOJDHCQ3BA8HBzFDXdhwBW03pkbuwzdz-T6_caylbg?multipart/alternative; 
boundary="A854E1CE55B241EFA7CBBDCF4B9DFCB1": 
1.0&=?UTF-8?Q?K=C3=B6p_biljetter_idag_till_The_Matrix_Resurrections!?=, 
10 Dec 2021 14:59:29 
+0100&329fc538580440abb21e9f4858643...@filmstaden.se&"Sebastian 
Nielsen" &"Filmstaden Medlem" 
&:*:*-1:apsis@filmstaden.se=One-Click&,


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.


Since the To: is included in the validation popup, it would also be 
evident to the original user that the To: address 

Re: [mailop] Idea for new internet standard: DKIM-QR

[Andrew C Aitchison via mailop]

On Sat, 11 Dec 2021, Sebastian Nielsen via mailop wrote:

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.

...  ...

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.

...  ...

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.


How does the phone app get access to the message to confirm that the 
QR-encoded signature matches the message ?



Best regards, Sebastian Nielsen


--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Idea for new internet standard: DKIM-QR

[Sebastian Nielsen via mailop]

The idea here was that it would be easier kind of, to create DKIM validation 
method, that only the sender and the sender's server need to be take part it, 
and then any user can validate the email, regardless of lack of support in the 
client or receiving server.

The result the program would show on-screen in a popup, along with the details 
of the email.
Like this:

"Signature is valid and verified to be signed by: yourbank.com" (yourbank.com 
is the domain taken from d= parameter)
"From: k...@yourbank.com" (From: header, if signed)
"To: y...@yourprovider.com" (To: header, if signed)
"Subject: Submit your details now to validate your account" (Subject, if signed)
"Date: Fri, 10 nov, 2021  18:23:55" (Date, if signed)


An user scanning such a QR code, would then look at phone screen, and then look 
on computer screen. Details in popup matches the email they see (so the QR code 
is not "stolen" from a legitimate email).
They now know the email is legitimate, they can now freely click links, fill in 
details and do their validation without fear of phishing.


I do agree that email clients should do DKIM validation, but getting every 
email client to do DKIM validation is a pretty tricky part. If the client 
software and receiving server can be left out of equation, then this could 
appear as apps in app-store where you easily can download a "DKIM-QR validator" 
like you can download a covidpass scanner from app store today, and if this 
gets traction enough, the feature would get implemented in phone's native 
cameras like Samsung has.


The tricky part would be to get this to become a internet-wide standard, that 
then goes out all news, and gets same traction as SPF and DKIM gets. Then banks 
will have their QR in emails "DKIM-QR: Scan to verify its genuine" and even 
Paypal could use such a feature.


-Ursprungligt meddelande-
Från: John Levine via mailop  
Skickat: den 12 december 2021 00:04
Till: mailop@mailop.org
Kopia: sebast...@sebbe.eu
Ämne: Re: [mailop] Idea for new internet standard: DKIM-QR

It appears that Sebastian Nielsen via mailop  said:
>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.

Since the DKIM signature is part of the mail message, if you want your phone to 
do that, why wouldn't you just have the phone's mail program validate the 
signature in the usual way?  Phones pick up mail by IMAP, so if they are 
sufficiently online to do IMAP, they can do DNS queries.

There's the more basic question of what the program would do with the result.
Surely everyone here knows that "valid signature" has no connection to "not 
spam"
or "not phish".

R's,
JOhn
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Idea for new internet standard: DKIM-QR

[John Levine via mailop]

It appears that Sebastian Nielsen via mailop  said:
>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.

Since the DKIM signature is part of the mail message, if you want your phone
to do that, why wouldn't you just have the phone's mail program validate
the signature in the usual way?  Phones pick up mail by IMAP, so if they are
sufficiently online to do IMAP, they can do DNS queries.

There's the more basic question of what the program would do with the result.
Surely everyone here knows that "valid signature" has no connection to "not 
spam"
or "not phish".

R's,
JOhn
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Idea for new internet standard: DKIM-QR

[Sebastian Nielsen via mailop]

Hi.

Im new here, and have been a mail server operator for quite a bit of a time.

 

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.

 

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 problem would appear if the
signature must be a signature of itself.

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.

 

URL-safe then means ; must be replaced with &, and all base64 strings should
be converted to URL-safe format, where + is replaced by - and / is replaced
by _, and any padding is removed.

On the end, a &-separated list of all signed header fields should be
included after a ?.

 

The header DKIM-Signature:
v=1;a=rsa-sha256;d=filmstaden.se;s=apsis;c=relaxed/relaxed; q=dns/txt;
t=1639144767;h=content-type:mime-version:subject:date:message-id:to:from:fee
dback-id:reply-to:list-unsubscribe-post:list-unsubscribe;bh=2hkchgJnI3p6njCQ
xrjr8vXfERYte+YcbH+rnJbgtEs=;b=Ulh8/Hi1eYO4tp9TgSWVSsHvi2AE7bL48/lR+F5IcIwJu
fNbaGafOMjQvj7c8+w3mkWneNskNYHJ1WBr6T+cMaUPgmiUiRRviyl2BWhmPivcfZVA/B4xSOcRW
2nMjOvWRldcrdkrz00g2XnwJwyyE02e8quaBjzODe4bTTUHWyNeap+kE9R0rAfTAcTvRYCOiqtUi
tIIU6a82W10C8rXR6Atx/wIl3mQAsP6sZpGckUtCfFPPdD1n6gCS6FDav7Ss7a2DQjzhkallSWaO
fQ5IpKiYqcLf1kTPdtL4Gw/TYbKzOJDHCQ3BA8HBzFDXdhwBW03pkbuwzdz+T6/caylbg==

 

Would in QR-form become:

dkim://v=1=rsa-sha256=filmstaden.se=apsis=relaxed/relaxed=dns_txt&
t=1639144767=content-type:mime-version:subject:date:message-id:to:from:fee
dback-id:reply-to:list-unsubscribe-post:list-unsubscribe=2hkchgJnI3p6njCQ
xrjr8vXfERYte-YcbH-rnJbgtEs==Ulh8_Hi1eYO4tp9TgSWVSsHvi2AE7bL48_lR-F5IcIwJu
fNbaGafOMjQvj7c8-w3mkWneNskNYHJ1WBr6T-cMaUPgmiUiRRviyl2BWhmPivcfZVA_B4xSOcRW
2nMjOvWRldcrdkrz00g2XnwJwyyE02e8quaBjzODe4bTTUHWyNeap-kE9R0rAfTAcTvRYCOiqtUi
tIIU6a82W10C8rXR6Atx_wIl3mQAsP6sZpGckUtCfFPPdD1n6gCS6FDav7Ss7a2DQjzhkallSWaO
fQ5IpKiYqcLf1kTPdtL4Gw_TYbKzOJDHCQ3BA8HBzFDXdhwBW03pkbuwzdz-T6_caylbg?multip
art/alternative;
boundary="A854E1CE55B241EFA7CBBDCF4B9DFCB1":
1.0&=?UTF-8?Q?K=C3=B6p_biljetter_idag_till_The_Matrix_Resurrections!?=,
10 Dec 2021 14:59:29
+0100&329fc538580440abb21e9f4858643...@filmstaden.se&"Sebastian Nielsen"
&"Filmstaden Medlem"
&:*:*-1:apsis
lem.no-re...@filmstaden.se=One-Click&,

 

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.

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