Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Murray S. Kucherawy]

On Mon, Feb 5, 2024 at 1:39 PM Steffen Nurpmeso  wrote:

> If a graphical user interface gives you a green "ok" button to
> click, or "red" otherwise, that is even better as in browser URL
> lines.  Then pop up a tree-view of message modifications and
> alertize where it broke, checkbox for is-this-really-an-evil.
>

I remember seeing a study presented at a conference that showed people
sometimes[*] click on links found in their spam folders.  If the act of
moving a suspect message out of the way is not enough to protect users from
bad actors, I can't imagine how a green-yellow-red light icon in the inbox
is going to do any better.

-MSK

[*] By this, I mean a statistically significant portion of them do.  The
number I remember is 18%, but I wouldn't be shocked to see it higher.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Dave Crocker]

On 2/5/2024 5:50 PM, Dave Crocker wrote:
we'd see reductions in user understanding, awareness and resistance 
abuse. 


sigh. /increases /in user understanding, awareness and resistance abuse.

reductions in user clicking errors, or somesuch

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Question about lone CR / LF

[Dave Crocker]

On 2/5/2024 4:57 PM, Murray S. Kucherawy wrote:

Interesting. Is that online anywhere?


You mean, as in a recording?  This was the early 1970s...  So, no.

This seems to be related to the topic:

https://scholar.archive.org/work/k2udwjcwqndofj6mw3fnn5jiky


 d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Dave Crocker]

On 2/5/2024 2:08 PM, Jim Fenton wrote:

On 5 Feb 2024, at 14:02, Dave Crocker wrote:

On 2/5/2024 1:56 PM, Jim Fenton wrote:

And you will also provide citations to refereed research about what you just 
asserted as well, yes?

Ahh, you want me to prove the negative. That's not exactly how these things go.

You said that the URL lock symbol failed. Asking for research to back that up 
is not asking for you to prove the negative.



Ahh.  Defending by attacking.  Nice.

But actually, given what I said, yes it is being asked to prove the 
negative.


I said it's been a failure. Failure means that after many years, it has 
not been a success.  Were the symbol successful, we'd see reductions in 
user understanding, awareness and resistance abuse.


Do we have serious data that it has been?  If so, where is it? Do we 
even have an anecdotal sense of widespread utility?  I think not.


But wait.  There's more...

All of the following are strong indicators of failure:

   /"In our study, we asked a cross-section
    of 528 web users
   , aged between 18 and 86
   years of age, a number of questions about the internet. Some 53% of
   them held a bachelor's degree or above and 22% had a college
   certificate, while the remainder had no further education. /

   /One of our questions was, "On the Google Chrome browser bar, do you
   know what the padlock icon represents/means?" /

   /Of the 463 who responded, 63% stated they knew, or thought they
   knew, what the padlock symbol on their web browser meant, but only
   7% gave the correct meaning."/

https://techxplore.com/news/2023-11-idea-padlock-icon-internet-browser.html

https://www.nextgov.com/cybersecurity/2019/06/fbi-warning-lock-icon-doesnt-mean-website-safe/157629/

   /'In an alert published Monday
   , the bureau’s Internet
   Crime Complaint Center, or IC3, warned that scammers are using the
   public’s trust in website certificates as part of phishing campaigns./

   /“The presence of ‘https’ and the lock icon are supposed to indicate
   the web traffic is encrypted and that visitors can share data
   safely,” the bureau wrote in the alert. “Unfortunately, cyber
   criminals are banking on the public’s trust of ‘https’ and the lock
   icon.” '/

https://theconversation.com/the-vast-majority-of-us-have-no-idea-what-the-padlock-icon-on-our-internet-browser-is-and-its-putting-us-at-risk-216581

https://www.sciencealert.com/theres-a-tiny-icon-on-your-screen-but-almost-nobody-knows-why

https://www.theverge.com/2023/5/3/23709498/google-chrome-lock-icon-web-browser-https-security-update-redesign

https://www.howtogeek.com/890033/google-chrome-is-ditching-the-lock-icon-for-websites/


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Steffen Nurpmeso]

Jim Fenton wrote in
 <3e7a38ef-4026-4943-8bc3-22516e3f1...@bluepopcorn.net>:
 |On 5 Feb 2024, at 14:02, Dave Crocker wrote:
 |> On 2/5/2024 1:56 PM, Jim Fenton wrote:
 |>> And you will also provide citations to refereed research about what \
 |>> you just asserted as well, yes?
 |>
 |> Ahh, you want me to prove the negative. That's not exactly how these \
 |> things go.
 |
 |You said that the URL lock symbol failed. Asking for research to back \
 |that up is not asking for you to prove the negative. I suspect there \
 |is research out there that backs up that statement, and I’m just asking \
 |for the same amount of rigor that you are asking for.

URL lock is one thing, the way to get there the other.
In fact i find it terribly annoying for so-called insecure
connections, those screaming pages and the large buttons to reject
and the small to really get where i want.  (Possibly even after
unfolding a visual layer.)

And i think the "do not ask again" should instead read "shall we
remember this very certificate for this very URL", and having
a date selector that cannot cross the not-after date of
a certificate, or some maximum time (that likely could be
configured, too).

Anyhow the lock symbol should possibly indicate whether it was
from a CA-pool, from a secured DNS TLSA or what, or from such
a user-accepted thing.  Do not ask me how.  Background colour,
configurable.

This problem is also the one of certificates and CA-pools, and
all that business.
But DKIM for example has the fantastic property of not even having
introduced the need for a specific DNS record, instead it simply
published the public certificate in a DNS record, so people could
start right away.
(If all protocols would support public certificate import/use via
DNS, i think this would be very nice.)
And GPG has its own way to detect certificates.
What i mean is, there is a more direct connection in between the
data and the certificate.
That seems much more doable and understandable than CA pools,
i think.  Especially since most normal people do not understand
the visualization of the browser giants.

For my text MUA (and mutt(1) does it quite similar) you will see

  [-- #1.1 35/1035 multipart/mixed --]
  [-- Signed data --]
  From: ...

for parts or in between header and body for others.  (Like i said,
that needs a MIME layer rewrite to be practical.)

That "Signed data" and such can be colourized.  Likely the colour
for errors would be the "error" one, which i set to red.
So on a 55 or 59 line console i find a single such line pretty
remarkable.
And .. i would not know of a better way.

P.S.: i do not think people stop eating chocolade.  Nor chips.
(Until the brain chip can make the serotonins flow and make you
think it is chocolete, while you are eating something different in
fact.  But care! that it does not report your addiction to some
data collector, then.)
But i think traffic lights are a world wide success.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Question about lone CR / LF

[Murray S. Kucherawy]

On Mon, Feb 5, 2024 at 8:50 AM Dave Crocker  wrote:

> OpenDKIM will not sign a message that fails basic RFC5322 header checks
> (e.g., "From" or "Date" is missing), but will place an
> Authentication-Results field indicating the message is malformed.  At some
> point, though, someone talked me into making it possible to bounce such a
> message in the filter.  I wish I could remember the full context.
>
> So you are enforcing an RFC5322 requirement for From and Date to be
> present, although the DKIM spec only requires signing From.
>
> Why are you doing that?
>
> Imagine RFC5322++ removes the requirement for Date. (In fact I had not
> remembered Date is required, going all the way back to RFC733. sigh.)  That
> requires remembering and changing DKIM code.
>
> I understand the desire to do this extra checking, but not the
> justification for giving in to it, inside DKIM.
>

Yeah, as I said, I wish I could remember.  It's a bit of a contradiction.
My best guess is that something was injecting messages without a Date field
knowing the MTA (sendmail, in this case) would add one.  But this had the
effect of causing the filter to oversign that field, so the MTA adding one
immediately invalidated the signature.  Adding this check avoided that
problem.


> It also allows for specification of things that are likely to be rewritten
> downstream (e.g., address canonicalization), which it can then simulate
> when computing its hashes, in order to make validation of the signature at
> the verifier more likely to succeed.[*]
>
> "likely to be rewritten downstream" is clearly part of local
> implementation design choices.
>

Yes indeed, though in my case I was compensating for an implementation
choice in the MTA to which the filter provides a service, and I don't have
direct control over the MTA's choices.

> While possibly quite reasonable to make for the implementation, they have
> nothing to do with the standards specification, other than to encourage
> writing standards that neither require nor inhibit such choices.
>
Yes, I agree that the specification should follow what I call the "pure"
angle, but also be abstract enough not to constrain implementation to
enable reality.

> (*) Lon ago, Knuth visited UCLA when I was there, and 'structured
> programming' was a hot topic.  He did a presentation to test a perspective
> that he later wrote up.  He observed that fully structured programs,
> without gotos, could sometimes make code /worse/.  He shows some code
> without any gotos that was correct but extremely difficult to read and
> understand.  Then he showed a version, with two loops -- one after the
> other -- and inside each was a goto into the other.  OMG.  But this code
> was clear, concise and easy to understand.
>

Interesting.  Is that online anywhere?

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Jim Fenton]

On 5 Feb 2024, at 14:02, Dave Crocker wrote:

> On 2/5/2024 1:56 PM, Jim Fenton wrote:
>> And you will also provide citations to refereed research about what you just 
>> asserted as well, yes?
>
>
> Ahh, you want me to prove the negative. That's not exactly how these things 
> go.

You said that the URL lock symbol failed. Asking for research to back that up 
is not asking for you to prove the negative. I suspect there is research out 
there that backs up that statement, and I’m just asking for the same amount of 
rigor that you are asking for.

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Dave Crocker]

On 2/5/2024 1:56 PM, Jim Fenton wrote:

nd you will also provide citations to refereed research about what you just 
asserted as well, yes?



Ahh, you want me to prove the negative. That's not exactly how these 
things go.


When someone says something works, the burden of documenting it is on them.

When someone says something does not work, it is sufficient to note that 
we have some decades of efforts and no serious documentation of 
efficacy.  And a very large scale example of it /not/ working, as I noted.


Bottom line: Claiming that we just need to train users better is a way 
of dodging any serious effort to deal with the topic.  The nature of 
human cognition, and the challenges of adequately encoding essential 
security-related information that is effective for 90% of users(*) works 
very aggressively against any claim that this is something that can 
usefully be dealt with by user training.


d/

(*)  When someone talks about 'average' users, one has left off (at 
least) half the user population...


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Jim Fenton]

On 5 Feb 2024, at 13:46, Dave Crocker wrote:

> On 2/5/2024 1:24 PM, Steffen Nurpmeso wrote:
>> I*totally*  disagree.
>> It is also a matter of education.
>
> Yeah.  No.  The standard example is the failure of the URL lock symbol.
>
> But given your certitude, please provide refereed research about persistent 
> behavioral change from email header security-related information.

And you will also provide citations to refereed research about what you just 
asserted as well, yes?

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Dave Crocker]

On 2/5/2024 1:24 PM, Steffen Nurpmeso wrote:

I*totally*  disagree.
It is also a matter of education.


Yeah.  No.  The standard example is the failure of the URL lock symbol.

But given your certitude, please provide refereed research about 
persistent behavioral change from email header security-related information.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20240205212412.Kq4PkTNC@steffen%sdaoden.eu>:
 |Dave Crocker wrote in
 | :
 ||On 2/5/2024 9:43 AM, Alessandro Vesely wrote:
 ||> It is debatable whether it is useful to display authentication 
 ||> information to the end user.  Personally, I like to see it. 
 ||
 ||At scale, there is no debate among UX professionals.  Its presence 
 ||varies between useless and confusing, for typical users.
 |
 |I *totally* disagree.
 |It is also a matter of education.
 |See in Germany (and Europe) we now have traffic lights on packaged
 |food, from red over yellow to green (in i think 6 steps), so
 |people will learn not to eat chips, sugarized cereals, and
 |chocolade.

P.S.:

For years i have, for the old BSD Mail fork i maintain, in
unreleased code (as the according MIME part is defunct and needs
a rewrite; ditto decryption, though that more obvious in the bad
case)

  + n_str_add_cp(, (mpp->m_content_info & CI_SIGNED_OK
  +? _("Signed data (good signature)")
  +: (mpp->m_content_info & CI_SIGNED_BAD
  +   ? _("Signed data (signature unverified)")
  +   : _("Signed data";

Over eight years, to be exact.  Too much talking, too less work.
The mutt(1) client also does this, quite heavily even.

In fact, quite the opposite, it seems that the graphical people
try the trivialmost beautifulmost surface without a content, like
those mostly young women who can be seen on the sidewalk of
certain streets, really.  But i have no experience with that.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Steffen Nurpmeso]

Dave Crocker wrote in
 :
 |On 2/5/2024 9:43 AM, Alessandro Vesely wrote:
 |> It is debatable whether it is useful to display authentication 
 |> information to the end user.  Personally, I like to see it. 
 |
 |At scale, there is no debate among UX professionals.  Its presence 
 |varies between useless and confusing, for typical users.

I *totally* disagree.
It is also a matter of education.
See in Germany (and Europe) we now have traffic lights on packaged
food, from red over yellow to green (in i think 6 steps), so
people will learn not to eat chips, sugarized cereals, and
chocolade.

 |Since some miniscule portion of the user population might like to see 
 |it, for whatever reason, it could make sense to make it available, but 
 |not as a default.

If a graphical user interface gives you a green "ok" button to
click, or "red" otherwise, that is even better as in browser URL
lines.  Then pop up a tree-view of message modifications and
alertize where it broke, checkbox for is-this-really-an-evil.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Dave Crocker]

On 2/5/2024 9:43 AM, Alessandro Vesely wrote:
It is debatable whether it is useful to display authentication 
information to the end user.  Personally, I like to see it. 


At scale, there is no debate among UX professionals.  Its presence 
varies between useless and confusing, for typical users.


Since some miniscule portion of the user population might like to see 
it, for whatever reason, it could make sense to make it available, but 
not as a default.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Alessandro Vesely]

On 05/02/2024 17:02, Hector Santos wrote:

On Feb 3, 2024, at 8:23 AM, Alessandro Vesely  wrote:

RFC 5322 specifies lists for From:, To:, Cc:, Bcc:, Reply-To:, 
Resent-From:, Resent-To:, Resent-Cc: and Resent-Bcc:.


My comment was regarding the MUA and the order data is read. I wonder 
which MUAs will display a list for Display fields From: and Resent-*. If 
any.  Are all of these OverSign targets?



Resent-* fields can be added multiple times, so they should not be 
[over]signed.



if we go down this road, the recommendation might be to always sign all 
headers, including the missing, including ARC and trace headers and 
before signing, reorder specific headers to DKIM-ready MUA read-order 
standards, if any.



Trace fields, signatures and all "transit" stuff should neither be 
signed nor oversigned.



Are MUAs now doing verifications and filtering failures?  Or is it the 
backend, the host, the MDA, that is still generally responsible for 
doing the verification and mail filtering before passing it on to users?



It is debatable whether it is useful to display authentication 
information to the end user.  Personally, I like to see it.


MUAs which have add-ons probably have one or more DKIM verifiers.  Some 
implement it natively.



Best
Ale
--







___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Question about lone CR / LF

[Hector Santos]

On 2/5/2024 11:50 AM, Dave Crocker wrote:


(*) Lon ago, Knuth visited UCLA when I was there, and 'structured 
programming' was a hot topic.  He did a presentation to test a 
perspective that he later wrote up.  He observed that fully 
structured programs, without gotos, could sometimes make code 
/worse/.  He shows some code without any gotos that was correct but 
extremely difficult to read and understand.  Then he showed a 
version, with two loops -- one after the other -- and inside each 
was a goto into the other.  OMG.  But this code was clear, concise 
and easy to understand.


I recall an old corporate project SE coding guideline: usage of a GOTO 
LABEL was allowed if the LABEL is within the reader's page view, i.e. 
25 lines (using 25x80 terminal standards).


--
Hector Santos,
https://santronics.com
https://winserver.com



___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Question about lone CR / LF

[Dave Crocker]

On 2/3/2024 1:13 PM, Murray S. Kucherawy wrote:
I generally agree with the idea that there's a layering problem here, 
i.e., that a DKIM filter should be able to safely presume that its 
input will comply with RFC5322 and not alter the message at all other 
than adding the signature.  But on review, it seems like I've tiptoed 
over that line from time to time in support of robustness in some form 
or another.  For instance:


The 'problem' is the difference between the abstract networking 
architecture, which can -- and for DKIM does -- have clean interfaces, 
versus software implementation that might have all sorts of local 
optimizations for efficiency, robustness, or the like.(*)


Keeping very clear about this difference is how we can get a simple, 
correct standards specification that permit the widest reasonable range 
of implementation choices.


The only danger in local optimizations is that they might embed requires 
on the world outside of DKIM that won't be remembered if/when that 
outside world changes.  (I'm sure /you/ wouldn't be guilty of that, of 
course, but most of us aren't from Canada.)



OpenDKIM will not sign a message that fails basic RFC5322 header 
checks (e.g., "From" or "Date" is missing), but will place an 
Authentication-Results field indicating the message is malformed.  At 
some point, though, someone talked me into making it possible to 
bounce such a message in the filter.  I wish I could remember the full 
context.


So you are enforcing an RFC5322 requirement for From and Date to be 
present, although the DKIM spec only requires signing From.


Why are you doing that?

Imagine RFC5322++ removes the requirement for Date. (In fact I had not 
remembered Date is required, going all the way back to RFC733. sigh.)  
That requires remembering and changing DKIM code.


I understand the desire to do this extra checking, but not the 
justification for giving in to it, inside DKIM.



It also allows for specification of things that are likely to be 
rewritten downstream (e.g., address canonicalization), which it can 
then simulate when computing its hashes, in order to make validation 
of the signature at the verifier more likely to succeed.[*]


"likely to be rewritten downstream" is clearly part of local 
implementation design choices.


While possibly quite reasonable to make for the implementation, they 
have nothing to do with the standards specification, other than to 
encourage writing standards that neither require nor inhibit such choices.


d/


(*) Lon ago, Knuth visited UCLA when I was there, and 'structured 
programming' was a hot topic.  He did a presentation to test a 
perspective that he later wrote up.  He observed that fully structured 
programs, without gotos, could sometimes make code /worse/.  He shows 
some code without any gotos that was correct but extremely difficult to 
read and understand.  Then he showed a version, with two loops -- one 
after the other -- and inside each was a goto into the other.  OMG.  But 
this code was clear, concise and easy to understand.


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Hector Santos]

> On Feb 3, 2024, at 8:23 AM, Alessandro Vesely  wrote:
> 
> On Fri 02/Feb/2024 14:34:22 +0100 Hector Santos wrote:
>> Of course, the MUA is another issue.  What read order should be expected for 
>> Oversign headers?  Each MUA can be different although I would think streamed 
>> in data are naturally read sequentially and the first display headers found 
>> are used in the UI.
> 
> 
> Yeah, which is the opposite of DKIM specified order.


>>   Only To: is allowed to be a list.
> 
> 
> RFC 5322 specifies lists for From:, To:, Cc:, Bcc:, Reply-To:, Resent-From:, 
> Resent-To:, Resent-Cc: and Resent-Bcc:.


My comment was regarding the MUA and the order data is read. I wonder which 
MUAs will display a list for Display fields From: and Resent-*. If any.  Are 
all of these OverSign targets?  

if we go down this road, the recommendation might be to always sign all 
headers, including the missing, including ARC and trace headers and before 
signing, reorder specific headers to DKIM-ready MUA read-order standards, if 
any.

Are MUAs now doing verifications and filtering failures?  Or is it the backend, 
the host, the MDA, that is still generally responsible for doing the 
verification and mail filtering before passing it on to users?


All the best,
Hector Santos

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim