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

[Steffen Nurpmeso]

Murray S. Kucherawy wrote in
 :
 |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.

Me neither.
But then, it is always easy to say this.  Whereas in practice, one
has "one of these days", one was left by his girl friend, someone
had a family member died, or mortally ill, is on drugs, just with
luck escaped a traffic accident and is hormonally overwhelmed, or
bored to death because the gambling hall has it closed day.  Ie my
neighbour here in the flat where i work plays for many hours
a day (but not professionally).
A study on spam folders is a thing, in the Google account they
moved Unicode/CLDR forum messages to spam (they were right, but
they pay to have a major vote).

However, here would be the real thing to step in, in my opinion,
in that the browser/graphical thing treats such user requests
inside declared spam folders with precaution, and adds additional
warnings, and maybe isolates the "opened whatever" very strictly.
(I personally have my normal browser in one "container", and one
with accounts, passwords and such, in another.  The filesystem
overlays do not cross.  What i can do.  But, *i* think, that would
be what makes up a *really* good interface; ie, protect against
weak moments if it is so "easily doable", and if the visited porn
site says it captured your box and you need to pay or everybody
knows, it is plain not true.  Then again, shall the browser ask
for video or microphone or password access (what to i know) for
followed spam folder links, even though i disabled that?  How
annoying.  I do not know.)

But back to the graphical lock symbol of browsers.  They visualize
certificate protection, and what does it really tell me despite
that someone paid for a certificate.  All a "normal" person can do
is to say "well, that is surely right", or, an american, maybe
even accepts it as such due to the system, like people seem to
refrain to disable Tesla data collection because of the speech in
the manual (talking the Mozilla car "study"), which effectively
says "data collection is part of our business, and if you like the
product and all that, it helps us getting better, etc etc", if
i understood that right.

I am pretty certain that if certificates would really "belong" to
domains, just like a DKIM public certificate belongs to a domain,
ie directly, and if there would be a good documentation, then
people would get a certainty, over time, you know.  You build up
trust.  This is what is in a MUA for S/MIME or PGP failures.  And
possibly in some for DKIM failures.  A direct failure, and
a noticeable one.

But given the noise that browsers make if a certificate cannot be
attested, maybe the lock symbol is pretty useless if the browser
warns on non-TLS-secured connections that pass authentication data
or the like.  I must admit that has not happened here for a long
time.

I continue to claim that in an email program, if there is a strong
visual indicator that a signature could not be verified, under
normal conditions, people would pay more attention to what they
do, than to a non-remarkable indicator (or, hm, none at all).

Maybe they would be more careful too, if any message looked at
within the spam folder would get such an indicator, each time anew
(ie off-on) when a new message is opened therein.  That would be
interesting.  It is all about consciousness, which can be trained
or "highlighted", i would think, all those studies aside.
For example the Japanese train drivers have to consciously point
their finger at what they are doing next.  (After some accident in
the past.)  They get trained to do that.  (I think they are also
now permanently video watched, at least black-box-alike, but i am
not certain.)

And, *if* there would be a cryptographically verifiable stack of
the message, say user A sends to M-L B sends to receiver C, and if
the signature fails, and if the signature of A was right before
B but now fails (ie all that the usual DKIM+ business), and if
i have a single traffic-light field that indeed is a button, and
upon press it shows that stack in tree-view, for example, with
traffic-light colours again, and then gives the option, beside the
red marker for M-L B, saying "accept that this sender breaks elder
signatures", or the like, 

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

[Steffen Nurpmeso]

Dave Crocker wrote in
 :
 |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:
 ...

..because that makes me sad over and over again..

 | of 528 web users

This is a laughable number.
Mind you, we had shampoos where they advertised that the thirteen
(13!) test persons reported positive things.

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

This has turned into a piece of dirt kicking shit, anti-russian,
silence otherwise, scientists happy to travel to southern seas for
their profession, low quality articles announced with big
headlines.  Maybe, of the "six human parasites you definitely
don't want to host", that thing is one of them.  Really.
"Why weightlifting is beneficial before and after the menopause"?
I won't get that hot!  Many years.  Now finished.
(Btw i am currently listening to The Lamb Lies Down On Broadway of
Genesis, and also: good luck, King Charles!, to save good Brits.)

 |https://www.sciencealert.com/theres-a-tiny-icon-on-your-screen-but-almos\
 |t-nobody-knows-why

Ok.  The problem with this, in my opinion, is that you and they
refer to URLs waved through because the certificate is valid
according to the installed CA pool.

 |https://www.theverge.com/2023/5/3/23709498/google-chrome-lock-icon-web-b\
 |rowser-https-security-update-redesign
 |
 |https://www.howtogeek.com/890033/google-chrome-is-ditching-the-lock-icon\
 |-for-websites/

I have chrome for android (ach i wish i would have a normal linux
with console applications for telephone and SMS, on
a fairly-produced pinephone or so; i got that one donated on top
of my decade old Nokia that is not smart.  I want to point that
out), and i can tell you how *noisy* that thing gets for
certificates that are NOT part of the CA pool.
It is an annoying mess!

The problem is that people get artificially torn apart.
You know, even if you look (and some graphicals give on-mouse-
over title boxes) you see things like Baltimore CyberTrust Root,
QuoVadis Root CA 2, Go Daddy Root Certificate Authority - G2, to
name a few.
Ah ya.  I feel absolutely secure now.  Someone paid for trust.

It would be different if we would throw away all that mess,
including complicated (imho) DANE, or even more complicated mess
(imho), and step to simple things like DKIM's published public
certificate (or only fingerprint), DNS query (chain) for the
(sub+) domain(s), load the certificate, and then users can have
the clear indication via relation of domain and certificate.
Maybe, in such a scenario, the lock symbol as such makes sense.

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

[Hector Santos]

Whoa!  I wondered about that!! Lock Icon was gone and it’s not a “switch” 
indication “options” icon.

You know, a good bit of the time is a programmer getting excited with a new UI 
API and switches to it!!  Imo, there was no need for that change,  Everything 
in the options was 100% about security and privacy related.  So what if the 
laymen didn’t know what it was. The default is set for unsecured 
communications. Focus on that, the secured defaults. The 10-20% experts that 
did know this intuitively with the lock icon was did not have an issue. 
Sometimes the first inclination is the best.  Go with your GUTS.  Always works 
in the long term.


All the best,
Hector Santos



> On Feb 5, 2024, at 8:50 PM, Dave Crocker  wrote:
> Om
> 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

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

[John Levine]

It appears that Murray S. Kucherawy   said:
>-=-=-=-=-=-
>
>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. ...

At session with large mail providers at a meeting a year or two ago, I
recall at least one of them said they'd made the links in the spam
folder non-clickable to prevent people from doing that. Otherwise some
users will click on everything, "just in case the spam filter got it
wrong."

R's,
John

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

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

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

[Alessandro Vesely]

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



Best
Ale
--






___
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 2/1/2024 6:38 AM, Alessandro Vesely wrote:

On Wed 31/Jan/2024 18:34:46 +0100 Hector Santos wrote:

If I add this feature to wcDKIM, it can be introduced as:

[X] Enable DKIM Replay Protection


That'd be deceptive, as DKIM replay in Dave's sense won't be 
blocked, while there can be other effects on signature robustness.



First, thanks to your and Murray's input.

I need to review Dave's "DKIM Replay" concerns.   Legacy systems have 
many entry points to create, import/export methods, transformation, 
filling missing fields, etc. Overall, I considered the potential 
"Replay" concern was about taking an existing signed message (from a 
purported "trusted signer" ) but MUA display fields, namely, To: and 
Subject: are missing or not signed.  These can potentially be replayed 
with tampered To:, Subject fields and exported.  The multiple 
5322.From headers MUA concern was highlighted many moons ago.  Easily 
Addressed with incoming SMTP filters rejecting multi-From messages.




A better sentence could be:

[X] Prevent further additions of this field


"This" meaning there is a header selection to monitor?    See below


Note that some packages allow choices such as

[ ] Sign and oversign only if present in the message
[ ] Oversign only if already present in the h= list
[ ] Oversign anyway 


Given how our package offer the signing defaults:

UseRequiredHeadersOnly = 1   # optional, 1 - use 
RequireHeaders
RequiredHeaders    = 
From:To:Date:Message-Id:Organization:Subject:Received*:List-ID
SkipHeaders    = 
X-*:Authentication-Results:DKIM-Signature:DomainKey-Signature:Return-Path
StripHeaders   = # optional, headers 
stripped by resigners


Basically, as the message to be signed headers are read in, each are 
checked again the RequiredHeaders (when enabled).  If missing, the 
header is not signed.  The exception is From: which is always 
signed.   Signed headers are added to the "h=" fields.


So how about this, if I follow this, new namespace fields:

OversignHeader.To = # default blank
OversignHeader.Subject =  # default blank
.
.
OversignHeader.Field-Name=   # future oversign header

This allows an oversign header to be signed if missing.  If correct, 
easily to update the code.


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.  Only To: is allowed 
to be a list.



--
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] Headers that should not be automatically oversigned in a DKIM signature?

[Alessandro Vesely]

On Wed 31/Jan/2024 18:34:46 +0100 Hector Santos wrote:

If I add this feature to wcDKIM, it can be introduced as:

[X] Enable DKIM Replay Protection



That'd be deceptive, as DKIM replay in Dave's sense won't be blocked, while 
there can be other effects on signature robustness.  A better sentence could be:


[X] Prevent further additions of this field

Note that some packages allow choices such as

[ ] Sign and oversign only if present in the message
[ ] Oversign only if already present in the h= list
[ ] Oversign anyway


Best
Ale
--




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

[Murray S. Kucherawy]

On Wed, Jan 31, 2024 at 9:35 AM Hector Santos  wrote:

> First time I have come across the term (“oversign”)  and it appears to be
> a feature with several products in the market. But checking the RFC, unless
> I missed it, it’s not a RFC defined term.  Replay is the term used.
>

You won't find it in any RFC or other formal place.  I think I
(accidentally) coined the term when I first added this capability to my
open source work.  I needed a short keyword to stick into a configuration
file to turn this on, and that's what came out.  We never went back and
added it to the RFC.

To me, the term connotes “redundant signing” beyond what is necessary or
> desired for a particular signing rule.


In a sense it is, but doing so also has a specific preventative side effect
that RFC 6376 describes.


> [X] Enable DKIM Replay Protection
>
> The F1 help will indicate the addition of headers, i.e.  To:, Subject:,
> etc. as empty field values are used to enforce the hashing binding of these
> potentially missing headers to the signature. If enabled, then these
> specific headers MUST be included in the list of headers to be signed and
> the headers MUST exist.  If not, the headers with empty values will be hash
> bound to the signature.
>
> Is that “Oversigning?”


To protect against this header attack, there's more to it than this.

RFC 6376 says that for each field named in "h=", find the next (bottom-up)
unused instance of that field and feed it to the hash; if there are no more
unused instances, skip it.  What this means for "From", for example, is
that if you oversign "from" (by listing it an extra time) on a
normally-formed message, the signer will always hash the one "From" you
have and then skip the extra one.  But on verification, if someone has
added an extra "From" field, both of them will get hashed, which means the
signature won't validate because what got hashed at the signer and what got
hashed at the verifier aren't the same.

So more generally, to "oversign" means to include an extra instance of the
field name(s) you want to protect from such insertions by adding one more
instance in "h=" beyond what's in the message at signing time.

It's not true that the header field MUST exist.  (You could add that
constraint, but it's not strictly necessary.)  I can say "h=banana:..." on
a regular message when that's not a field you expect to be on the message.
If a "Banana" field gets added anywhere, validation will fail, but it
otherwise doesn't interfere with anything.

For the code I wrote, the list of fields to sign and the list of fields to
oversign are separate.  The oversign list is just tacked on to the end of
the "h=" before the header hash is finalized.  The two lists don't have to
overlap at all (though they usually do).

Finally, I'd be careful about calling this "Replay Protection".  It
addresses only one type of replay attack.  The sort of replay attack that
caused this group to recharter isn't prevented by oversigning, for example.

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

[Hector Santos]

> On Jan 19, 2024, at 8:41 PM, John R Levine  wrote:
> 
> Manfred said:
>> (Seems like "seal"ing would be a better term than "oversign"ing.)
> 
> We've called it oversigning for a decade now.
> 

Interesting.  

First time I have come across the term (“oversign”)  and it appears to be a 
feature with several products in the market. But checking the RFC, unless I 
missed it, it’s not a RFC defined term.  Replay is the term used.

To me, the term connotes “redundant signing” beyond what is necessary or 
desired for a particular signing rule.   If I add this feature to wcDKIM, it 
can be introduced as:

[X] Enable DKIM Replay Protection

The F1 help will indicate the addition of headers, i.e.  To:, Subject:, etc. as 
empty field values are used to enforce the hashing binding of these potentially 
missing headers to the signature. If enabled, then these specific headers 
MUST be included in the list of headers to be signed and the headers MUST 
exist.  If not, the headers with empty values will be hash bound to the 
signature.

Is that “Oversigning?”

Perhaps. Imo, it is redundant header(s) signing when it may not be required for 
certain DKIM signing routes.  

What is most important is what it is suppose to help address - DKIM Replay 
hacks.

All the best,
Hector Santos




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

[John R Levine]

Manfred said:

(Seems like "seal"ing would be a better term than "oversign"ing.)


We've called it oversigning for a decade now.

R's,
John

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

John Levine wrote in
 <20240119192026.dedff8104...@ary.qy>:
 |It appears that Evan Burke   said:
 |>> Insisting on using the same term for these two different cases has an
 |>> academic purity to it, but has already been demonstrated to be destructi\
 |>> ve
 |>> in practical terms, because it creates confused discussion.
 |
 |>No, that's exactly backwards. The oversigning case is a subset of the
 |>general DKIM replay case, because mitigation techniques for general DKIM
 |>replay - they do exist, though they are imperfect - also apply to cases
 |>where header addition has taken place. Oversigning is a defense against \
 |>the
 |>subset of DKIM replay where headers have been added, but not the general
 |>case.
 |
 |I think you've rather proved Dave's point. Resending the identical
 |message and mutating a signed message with duplicate headers are
 |different problems even though they have some technical overlap.
 |
 |I don't really care what people call them but it would be nice if they

(Seems like "seal"ing would be a better term than "oversign"ing.)

 |had different names so we don't have to use six round trip messages
 |each time to figure out which one we're referring to.
 |
 |Pretty much everywhere except this mailing list "DKIM Replay" means
 |the former, resending the identical message.

--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
 <54bcc79e-2cec-4c49-8a5c-0ef64db68...@dcrocker.net>:
 |On 1/19/2024 6:51 AM, Al Iverson wrote:
 ...
 |[.]the scenario of 
 |sending to a collaborating receiver and re-posting a message that has no 
 |differences except the envelope rcpt-to value, does not have a know 
 |solution.

There would be a RFC 6376 backward compatible "solution" with
per-receiver-domain DKIM-Subsignature that fixates the SMTP
recipients for a particular address.

Ie include a flag in the DKIM signature that signals this new
methodology, and instead of transferring one email to all
receiving domains, send per-receiver-domain instances that contain
a DKIM-Subsignature header field that includes envelope receivers
especially for this receiver domain.

Then an upgraded DKIM verifier on the receiver side could,
announced by the flag in the DKIM signature, ensure that only
those receivers which are included in the DKIM-Subsignature are
actually addressed, and any bad actor that tries to replay the
message can be detected since it does not include the
DKIM-Subsignature that verifies against the DKIM key of the
original sender.

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

Steffen Nurpmeso wrote in
 <20240120002211.9zE1qqLr@steffen%sdaoden.eu>:
 ...
 |[.]people which[.]

So that is "people who", and then i wanted to apologise for naming
Mr. Kucherawy "Kucheraway" in one of all those of my posts.

Have a nice weekend i wish from Germany,

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

Emanuel Schorsch wrote in
 :
 |I don't have a strong horse in this race. But I'll just chime in that from
 |my perspective I was thinking of both of these as DKIM Replay. I have been
 |calling any case where the DKIM signature is not broken and the spammer
 |resends multiple copies as DKIM Replay.

I also not, but if i insist on the "sealing" that RFC 6376
describes then a solution for the one you describe was created
alongside the standard as such?

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

Steffen Nurpmeso wrote in
 <20240119235632.VOlkKoIX@steffen%sdaoden.eu>:
 |Dave Crocker wrote in
 | <54bcc79e-2cec-4c49-8a5c-0ef64db68...@dcrocker.net>:
 ||On 1/19/2024 6:51 AM, Al Iverson wrote:
 ...
 ||[.]does not have a know 
 ||solution.
 |
 |There would be a RFC 6376 backward compatible "solution" with
 |per-receiver-domain DKIM-Subsignature that fixates the SMTP
 |recipients for a particular address.
 |
 |Ie include a flag in the DKIM signature that signals this new
 |methodology, and instead of transferring one email to all
 |receiving domains, send per-receiver-domain instances that contain
 |a DKIM-Subsignature header field that includes envelope receivers
 |especially for this receiver domain.
 |
 |Then an upgraded DKIM verifier on the receiver side could,
 |announced by the flag in the DKIM signature, ensure that only
 |those receivers which are included in the DKIM-Subsignature are
 |actually addressed, and any bad actor that tries to replay the
 |message can be detected since it does not include the
 |DKIM-Subsignature that verifies against the DKIM key of the
 |original sender.

I am not truly the right person to write a draft, because of my
english and my problems to stick within a fixed scaffolding.

Also the "idea" i hm developed did not had any feedback, except by
Jesse Thompson, who gave a very good suggestion; .. which is ok,
but i personally do not feel very confident to create a standard
without feedback from people which drive software which would need
to be adopted to comply.

Especially, and mostly, actually, the forking of the message is
something that does not happen today.  In order to send
per-receiver-domain message copies, a milter must adjust the
return list to one receiver domain, and, as necessary, recreate
the message to send it to the remaining receiver-domains; these
copies then, well, either have to undergo "the same procedure",
*again*, or require a special M[TS]A entry point that is fed with
ready-to-takeoff message copies.

All this is doable, but it is, as far as i know, not done today.
How can i -- and that is especially i, who never wrote an IETF
draft -- create a standard draft that requires such a new or
modified processing pipeline, without any feedback; no
improvements, no disagreements, no agreements.  That is not much.

Also i have very few spare time, i do not get paid for this
either, and diving into writing a draft requires time.  Maybe even
weeks.  Having said all that, maybe in Spring i could find some
cycles to look into the IETF scaffolding framework.  But like
i said last year, i do not need to see my name on some standard
document (even in the THANKS apartment i feel uncomfortable),
i would prefer to write software in the little time i have.
But i mean i could also simply take an existing draft, and place
in there the few paragraphs that are necessary to describe the
idea: it is not much, actually.

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

[Emanuel Schorsch]

I don't have a strong horse in this race. But I'll just chime in that from
my perspective I was thinking of both of these as DKIM Replay. I have been
calling any case where the DKIM signature is not broken and the spammer
resends multiple copies as DKIM Replay.

On Fri, Jan 19, 2024 at 11:20 AM John Levine  wrote:

> It appears that Evan Burke   said:
> >> Insisting on using the same term for these two different cases has an
> >> academic purity to it, but has already been demonstrated to be
> destructive
> >> in practical terms, because it creates confused discussion.
>
> >No, that's exactly backwards. The oversigning case is a subset of the
> >general DKIM replay case, because mitigation techniques for general DKIM
> >replay - they do exist, though they are imperfect - also apply to cases
> >where header addition has taken place. Oversigning is a defense against
> the
> >subset of DKIM replay where headers have been added, but not the general
> >case.
>
> I think you've rather proved Dave's point. Resending the identical
> message and mutating a signed message with duplicate headers are
> different problems even though they have some technical overlap.
>
> I don't really care what people call them but it would be nice if they
> had different names so we don't have to use six round trip messages
> each time to figure out which one we're referring to.
>
> Pretty much everywhere except this mailing list "DKIM Replay" means
> the former, resending the identical message.
>
> R's,
> John
>
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim
>
___
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?

[John Levine]

It appears that Evan Burke   said:
>> Insisting on using the same term for these two different cases has an
>> academic purity to it, but has already been demonstrated to be destructive
>> in practical terms, because it creates confused discussion.

>No, that's exactly backwards. The oversigning case is a subset of the
>general DKIM replay case, because mitigation techniques for general DKIM
>replay - they do exist, though they are imperfect - also apply to cases
>where header addition has taken place. Oversigning is a defense against the
>subset of DKIM replay where headers have been added, but not the general
>case.

I think you've rather proved Dave's point. Resending the identical
message and mutating a signed message with duplicate headers are
different problems even though they have some technical overlap.

I don't really care what people call them but it would be nice if they
had different names so we don't have to use six round trip messages
each time to figure out which one we're referring to.

Pretty much everywhere except this mailing list "DKIM Replay" means
the former, resending the identical message.

R's,
John

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

[Evan Burke]

On Fri, Jan 19, 2024 at 7:01 AM Dave Crocker  wrote:

> On 1/19/2024 6:51 AM, Al Iverson wrote:
>
> I'm
> sort of boggling at the attempt to keep potential header changes and
> DKIM oversigning out of the exploit definition and potential solution
> consideration. I just don't think it makes sense to exclude this.
>
>
> It makes sense because oversigning is sufficient to cover the cases of
> re-posting that 'merely' add header fields, whereas the scenario of sending
> to a collaborating receiver and re-posting a message that has no
> differences except the envelope rcpt-to value, does not have a know
> solution.
>
> Insisting on using the same term for these two different cases has an
> academic purity to it, but has already been demonstrated to be destructive
> in practical terms, because it creates confused discussion.
>

No, that's exactly backwards. The oversigning case is a subset of the
general DKIM replay case, because mitigation techniques for general DKIM
replay - they do exist, though they are imperfect - also apply to cases
where header addition has taken place. Oversigning is a defense against the
subset of DKIM replay where headers have been added, but not the general
case.
___
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 1/19/2024 6:51 AM, Al Iverson wrote:

I'm
sort of boggling at the attempt to keep potential header changes and
DKIM oversigning out of the exploit definition and potential solution
consideration. I just don't think it makes sense to exclude this.



It makes sense because oversigning is sufficient to cover the cases of 
re-posting that 'merely' add header fields, whereas the scenario of 
sending to a collaborating receiver and re-posting a message that has no 
differences except the envelope rcpt-to value, does not have a know 
solution.


Insisting on using the same term for these two different cases has an 
academic purity to it, but has already been demonstrated to be 
destructive in practical terms, because it creates confused discussion.


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?

[Al Iverson]

I don't know what other people have decided off in spec land to call
this, but here what I'm seeing is somebody taking a message, adding
headers (or not), re-injecting the message to another recipient, it
being received with DKIM signature intact, that's DKIM replay. I'm
sort of boggling at the attempt to keep potential header changes and
DKIM oversigning out of the exploit definition and potential solution
consideration. I just don't think it makes sense to exclude this. If I
were going to nit pick, I guess I'd say that RFC 6376 section 8.6
doesn't seem to be specific enough to exclude any of this from the
definition of DKIM replay; it says nothing yay or nay about the
potential for additional headers. And I think that's fine, as exploits
evolve and it would be limiting to have done otherwise.

Cheers,
Al Iverson

-- 

Al Iverson / Deliverability blogging at https://www.spamresource.com
Subscribe to the weekly newsletter at https://ml.spamresource.com
DNS Tools: https://xnnd.com / (312) 725-0130 / Chicago (Central Time)

___
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 1/18/2024 1:46 PM, Dave Crocker wrote:
The issue is not whether those broader concerns are... concerns.  They 
are.  But the topic of DKIM Replay has to do with a scenario that is 
affected by things like oversigning.


sigh.  sorry. small, insignificant typo, merely flipping the sign bit...

   But the topic of DKIM Replay has to do with a scenario that is /NOT/
   affected by things like oversigning.

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]

Dave Crocker wrote in
 <82f48c8d-b89c-404f-87ac-4619628dd...@dcrocker.net>:
 |On 1/16/2024 3:57 PM, Evan Burke wrote:
 ...
 |> Without oversigning those headers, DKIM would pass,
 |
 |Yes, oversigning is useful.  And it has been useful for a very long 

Just to make that clear to myself, who is currently writing his
first simple DKIM sign-only milter.  This refers to 5.4 of RFC
6376, namely

  ...
Signers MAY include the header field name in the "h=" tag even
if that header field does not exist in the message)
  ...
  INFORMATIVE RATIONALE: This allows Signers to explicitly assert
  the absence of a header field; if that header field is added
  later, the signature will fail.

  INFORMATIVE NOTE: A header field name need only be listed once
  more than the actual number of that header field in a message at
  the time of signing in order to prevent any further additions.
  For example, if there is a single Comments header field at the
  time of signing, listing Comments twice in the "h=" tag is
  sufficient to prevent any number of Comments header fields from
  being appended; it is not necessary (but is legal) to list
  Comments three or more times in the "h=" tag.

 |time.  It is important to do.  So it is good to have DKIM modules 
 |support this capability.
 |
 |However the abuse scenarios which are reduced or eliminatoversigning are 
 |outside the scope of the recent abuse that is being called DKIM Replay.

--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 1/16/2024 3:57 PM, Evan Burke wrote:


DKIM Replay re-sends an /unmodified/ copy of the message, where
only the SMTP RCPT-To is different.  DKIM doesn't (and can't)
cover that SMTP command.


I'd call it DKIM replay if the signature is intact.


You are, of course, free to use any term you want, in any way you want.

However for group discussions to be productive, common, shared 
terminology is needed.


The term "DKIM Replay" has become a term of art, referring to efforts at 
countering a specific form of abuse, and it is the form I described.


One of the difficulties in getting traction with the effort -- beyond 
the actual technical challenges -- has been various people's tendency to 
use the term more broadly, generally for any type of abuse-based 
forwarding of existing text that was signed.


The issue is not whether those broader concerns are... concerns. They 
are.  But the topic of DKIM Replay has to do with a scenario that is 
affected by things like oversigning.




Without oversigning those headers, DKIM would pass,


Yes, oversigning is useful.  And it has been useful for a very long 
time.  It is important to do.  So it is good to have DKIM modules 
support this capability.


However the abuse scenarios which are reduced or eliminatoversigning are 
outside the scope of the recent abuse that is being called DKIM Replay.


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?

[Evan Burke]

On Tue, Jan 16, 2024 at 8:58 AM Dave Crocker  wrote:

> Ahh. OK.  Oversigning, to prevent sending a version of the message onward
> -- but with one or another field added -- is generally viewed as a Good
> Thing. I have tried to locate one, but I believe there are some best
> practices documents that give advice about doing it.
>
> However it is not what is meant by DKIM Replay.
>
> DKIM Replay re-sends an /unmodified/ copy of the message, where only the
> SMTP RCPT-To is different.  DKIM doesn't (and can't) cover that SMTP
> command.
>

I'd call it DKIM replay if the signature is intact. For a little while,
attackers used duplicate Subject and/or Date headers (subject to replace an
innocuous subject line used on our platform to avoid getting caught by
filters, replaced with their spam payload subject line, and Date presumably
to avoid negative reputation effects from old Date headers in replays).

Without oversigning those headers, DKIM would pass, since the original
headers were still present and unmodified, in addition to the new headers
added by the attacker.  As noted by others, these duplicate headers violate
RFCs, and I saw several mailbox providers add tighter checking of mail
against RFCs as a defense against this type of DKIM replay.
___
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 16/01/2024 17:52, Mike Hillyer wrote:


One example of this documented is Brian Godiksen's blog post at 
https://www.socketlabs.com/blog/dkim-replay-attacks-preventive-measures-to-protect-email-deliverability


The post explicitly mentions subject, to, from, date and reply-to 
headers.  I don't know if signing technical headers (e.g. MIMI-Version) 
can help against replay, but it weakens signature's resilience.


The post says "One interesting aspect to these attacks is that messages 
are commonly modified by the attacker."  I guess they try and escape 
ESP's content filtering on outgoing messages...



Best
Ale
--



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

[John Levine]

It appears that Mike Hillyer   said:
>In the interest of the rule of unforseen consequences, we're trying to avoid 
>oversigning any headers that would break further downstream processing. Does 
>anyone
>know of any headers that *should* be DKIM signed, but *should not* be 
>oversigned?

Offhand, I can't think of any.

DKIM signatures are only defined for RFC5322 messages, and anything
with two From: or Subject: or Date: headers isn't an RFC5322 message. A
DKIM validator really shouldn't accept an invalid message, and a spam
filter should give a very high score to duplicate headers, but I realize
theory and practice diverge here.

R's,
John

___
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 1/16/2024 8:52 AM, Mike Hillyer wrote:

In my discussions, I've been told of malicious parties sending messages
with blank subject headers (not missing, the header name is there with
no value), and adding a second subject header with the payload subject
line, and some MUAs will either show the subject because it is higher up
  in the header list, or because the original was blank, but the DKIM
validates because the blank subject header is in the signature and is
the one checked.


Ahh. OK.  Oversigning, to prevent sending a version of the message 
onward -- but with one or another field added -- is generally viewed as 
a Good Thing. I have tried to locate one, but I believe there are some 
best practices documents that give advice about doing it.


However it is not what is meant by DKIM Replay.

DKIM Replay re-sends an /unmodified/ copy of the message, where only the 
SMTP RCPT-To is different.  DKIM doesn't (and can't) cover that SMTP 
command.



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?

[Mike Hillyer]

In my discussions, I've been told of malicious parties sending messages with 
blank subject headers (not missing, the header name is there with no value), 
and adding a second subject header with the payload subject line, and some MUAs 
will either show the subject because it is higher up in the header list, or 
because the original was blank, but the DKIM validates because the blank 
subject header is in the signature and is the one checked. We already sign 
headers in the header list that are not present, but we want to sign an extra 
nil header for this kind of scenario, as long as what I said before is true, 
that the header should be DKIM signed, but additional header instances may be 
needed further into the flow.

One example of this documented is Brian Godiksen's blog post at 
https://www.socketlabs.com/blog/dkim-replay-attacks-preventive-measures-to-protect-email-deliverability

Mike




From: Dave Crocker 
Sent: Tuesday, January 16, 2024 11:34 AM
To: Mike Hillyer 
Cc: ietf-dkim@ietf.org 
Subject: Re: [Ietf-dkim] Headers that should not be automatically oversigned in 
a DKIM signature?
 
On 1/16/2024 8:18 AM, Mike Hillyer wrote:
In an effort to make it easier for our users to prevent DKIM replay 
attacks, we're looking at adding an option to our DKIM signing module to
 automatically oversign headers in the DKIM signature, adding an 
additional entry in the headers list to assert a null header, preventing
 a malicious third party from adding an additional header but having the
 message still validate as DKIM because only one instance of the header 
was listed in the signature.
While I applaud your goal, it is not immediately obvious to me how this can 
reduce or eliminate DKIM Replay.
Could you provide an example?
Thanks.
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 1/16/2024 8:18 AM, Mike Hillyer wrote:

In an effort to make it easier for our users to prevent DKIM replay
attacks, we're looking at adding an option to our DKIM signing module to
  automatically oversign headers in the DKIM signature, adding an
additional entry in the headers list to assert a null header, preventing
  a malicious third party from adding an additional header but having the
  message still validate as DKIM because only one instance of the header
was listed in the signature.


While I applaud your goal, it is not immediately obvious to me how this 
can reduce or eliminate DKIM Replay.


Could you provide an example?

Thanks.

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

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

[Mike Hillyer]

Hello All,

In an effort to make it easier for our users to prevent DKIM replay attacks, 
we're looking at adding an option to our DKIM signing module to automatically 
oversign headers in the DKIM signature, adding an additional entry in the 
headers list to assert a null header, preventing a malicious third party from 
adding an additional header but having the message still validate as DKIM 
because only one instance of the header was listed in the signature.

To that end, we're trying to make this as easy as possible for our users out of 
the box, ideally just having Oversign = True as an option, where any header 
listed for signing would then get n+1 entries in the header list, so that any 
duplicate headers present in the message result in one more entry. So one 
header gets two entries, two headers gets three, etc.

In the interest of the rule of unforseen consequences, we're trying to avoid 
oversigning any headers that would break further downstream processing. Does 
anyone know of any headers that *should*​ be DKIM signed, but *should not* be 
oversigned?

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