Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Vsevolod Stakhov via mailop]

On 17/05/2024 15:12, Taavi Eomäe via mailop wrote:

Hi!

As part of coordinated disclosure, I am sharing it here as well. In 
short, using the approach described below, attackers can replace the 
entire contents of a letter, in a way the letters still pass DKIM’s 
cryptographic checks. This also means these forged letters can be easily 
replayed to reach their victims. This subverts many of the expectations 
operators have about DKIM signatures, DMARC and BIMI.


Although some of these dangers have been known for a while (some parts 
are even described in the RFC itself), things like the threat landscape, 
our approach and the extent to which this can be abused have changed. In 
our opinion previously suggested and (rarely) implemented mitigations do 
not reduce these risks sufficiently.


We hope that with some cooperation from mail operators improved defense 
measures can be implemented to strengthen DKIM for everyone.



A longer description with images is available here: 
https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/




After some thinking, I have decided[1] that Rspamd should reject DKIM 
signatures where l tag covers less than 90% of the message body. I hope 
it should reduce the potential attack surface.


[1]: https://github.com/rspamd/rspamd/pull/4975
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Alessandro Vesely via mailop]

On Sat 18/May/2024 19:37:44 +0200 Dave Crocker via mailop wrote:

On 5/17/2024 7:12 AM, Taavi Eomäe via mailop wrote:


We hope that with some cooperation from mail operators improved defense 
measures can be implemented to strengthen DKIM for everyone.


As I recall, the original intent was to permit successful use of DKIM in spite 
of mailing lists' addition of footer text.



Ironically, to verify a DKIM signature after MLM transformation is more 
difficult, IME, if the original signature had l= than otherwise.  The reason is 
that using l= implies signing Content-Type:, which is a technical field that 
MLMs /need/ to change, and recovering its original value requires too much 
guesswork.


Best
Ale
--





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

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Dave Crocker via mailop]

On 5/18/2024 2:12 PM, Gellner, Oliver via mailop wrote:

Changing the existing DKIM specification is probably a big challenge.


Yes, but it can be done as a separate specification that is classed as 
an 'update' to the DKIM spec.


fwiw, I've heard rumors of some industry folk wanting to produce "DKIM 
2", but the rumors have carried no details to indicate what the 
substance might be.




Another approach could be to update the wip BIMI specification with a
statement that a DMARC pass must be ignored if it is solely based on
valid DKIM signatures with length attributes.


Please no.  There has been some tendency to effect a change in an 
underlying specification by adding a constraint onto a specification 
that uses the underlying one.


The result has been basic modifications to email, without changing basic 
specifications.


Note, for example, that DMARC has broken the From: field, so it now 
serves as what the Sender: field was designed for.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Bill Cole via mailop]

On 2024-05-18 at 17:12:11 UTC-0400 (Sat, 18 May 2024 21:12:11 +)
Gellner, Oliver via mailop 
is rumored to have said:


On 18.05.2024 at 21:02 Dave Crocker via mailop wrote:

[...]
Seems like the right approach is to seek community-wide pressure to 
deprecate it.  First through operational pressure and then with an 
update to the spec.


I‘m with you on the operational pressure to deprecate the length 
attribute, however this requires MTA software that allows you to 
differentiate between DKIM signatures with and without l. Is there any 
other than the mentioned mailauth, which doesn’t seem to have a 
direct MTA integration.


It would be easy enough to write a SpamAssassin rule for this or to make 
such a check part of the local config for MIMEDefang or MailMunge (both 
of which use arbitrary Perl for their local config.) It could even be 
done in a Postfix header_check if you don't ask much subtlety of it.


Changing the existing DKIM specification is probably a big challenge. 
Another approach could be to update the wip BIMI specification with a 
statement that a DMARC pass must be ignored if it is solely based on 
valid DKIM signatures with length attributes. The BIMI specification 
already contains such exceptions, like DMARC quarantine policies that 
must be ignored if they include a pct value of less than 100, so this 
wouldn’t be completely new grounds.


BIMI seems like a very gentle tool for operational pressure.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo@toad.social and many *@billmail.scconsult.com 
addresses)

Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Gellner, Oliver via mailop]

> On 18.05.2024 at 21:02 Dave Crocker via mailop wrote:
>
> On 5/17/2024 7:12 AM, Taavi Eomäe via mailop wrote:
>> Although some of these dangers have been known for a while (some parts are 
>> even described in the RFC itself), things like the threat landscape, our 
>> approach and the extent to which this can be abused have changed. In our 
>> opinion previously suggested and (rarely) implemented mitigations do not 
>> reduce these risks sufficiently.
>> We hope that with some cooperation from mail operators improved defense 
>> measures can be implemented to strengthen DKIM for everyone.
>
>
> As I recall, the original intent was to permit successful use of DKIM in 
> spite of mailing lists' addition of footer text.
>
> I think the view of damage from DKIM failure and/or abuse was rather more 
> benign than suits today's email world.
>
> It wasn't a great feature at the time and now it is worse than that.
>
> Seems like the right approach is to seek community-wide pressure to deprecate 
> it.  First through operational pressure and then with an update to the spec.

I‘m with you on the operational pressure to deprecate the length attribute, 
however this requires MTA software that allows you to differentiate between 
DKIM signatures with and without l. Is there any other than the mentioned 
mailauth, which doesn’t seem to have a direct MTA integration.

Changing the existing DKIM specification is probably a big challenge. Another 
approach could be to update the wip BIMI specification with a statement that a 
DMARC pass must be ignored if it is solely based on valid DKIM signatures with 
length attributes. The BIMI specification already contains such exceptions, 
like DMARC quarantine policies that must be ignored if they include a pct value 
of less than 100, so this wouldn’t be completely new grounds.

—
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Atro Tossavainen via mailop]

> Other than that, I'm with you, it is a fraction of a percent of signed
> mail, not common at all.

I'm with Dr Levine; I just looked at all the stuff our spamtrap system
has received in May so far (n~=8M). The exact number I came up with is
0.6%. Also, the percentage of signed mail out of all mail seen is ~60%.

-- 
Atro Tossavainen, Founder, Partner
Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
Tallinn, Estonia
tel. +372-5883-4269, https://www.koliloks.eu/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Dave Crocker via mailop]

On 5/17/2024 7:12 AM, Taavi Eomäe via mailop wrote:
Although some of these dangers have been known for a while (some parts 
are even described in the RFC itself), things like the threat 
landscape, our approach and the extent to which this can be abused 
have changed. In our opinion previously suggested and (rarely) 
implemented mitigations do not reduce these risks sufficiently.


We hope that with some cooperation from mail operators improved 
defense measures can be implemented to strengthen DKIM for everyone. 



As I recall, the original intent was to permit successful use of DKIM in 
spite of mailing lists' addition of footer text.


I think the view of damage from DKIM failure and/or abuse was rather 
more benign than suits today's email world.


It wasn't a great feature at the time and now it is worse than that.

Seems like the right approach is to seek community-wide pressure to 
deprecate it.  First through operational pressure and then with an 
update to the spec.


d/

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

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

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Dave Crocker via mailop]

On 5/17/2024 7:12 AM, Taavi Eomäe via mailop wrote:
Although some of these dangers have been known for a while (some parts 
are even described in the RFC itself), things like the threat 
landscape, our approach and the extent to which this can be abused 
have changed. In our opinion previously suggested and (rarely) 
implemented mitigations do not reduce these risks sufficiently.


We hope that with some cooperation from mail operators improved 
defense measures can be implemented to strengthen DKIM for everyone. 



As I recall, the original intent was to permit successful use of DKIM in 
spite of mailing lists' addition of footer text.


I think the view of damage from DKIM failure and/or abuse was rather 
more benign than suits today's email world.


It wasn't a great feature at the time and now it is worse than that.

Seems like the right approach is to seek community-wide pressure to 
deprecate it.  First through operational pressure and then with an 
update to the spec.


d/

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

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

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[John Levine via mailop]

It appears that Bill Cole via mailop  
said:
>Who uses it?

In my logs most of the l= tags are l=1 on that libertarian newsletter,
and one or two other newsletters.

I see that Verisign puts an l= in the mail their employees send with the
real message length.

Other than that, I'm with you, it is a fraction of a percent of signed
mail, not common at all.

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

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[John Levine via mailop]

It appears that Slavko via mailop  said:
>I feel as the problem lies elsewhere. Perhaps just mentioned gigants
>fails properly parse the l= tag (or even do not parse it at all) and their
>UI shows whole message (or all its parts) as signed, ...

That's not how DKIM works, and not how l= works. Either the signature
validates or not. Back in the day I recall people proposing that the
mail program somehow highlight the signed parts or grey out the
unsigned parts.  That was ridiculous then and no less ridiculous now.

Keep in mind that these days, more often than not MUAs don't even show
the address in the From header.

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

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[John Levine via mailop]

It appears that Taavi Eomäe via mailop  said:
>> Every a few months we see a paper / blogpost that passes SPF / DKIM / 
>> DMARC. So maybe requiring both SPF and DKIM for BIMI would be a good idea.
>
>Both together might make sending a bit too error-prone. Hardening DKIM 
>seems more doable. I hope that IETF's mailmaint gets to discuss topics 
>like these and maybe we'll see some standardized approaches.

If you want to propose something for mailmaint, write up a draft and send it in.

There is no chance that anyone's interested in changing DKIM, but I
could see an applicability statement or BCP that offered advice on
what to sign and what options (not) to use.

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

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Slavko via mailop]

Dňa 18. mája 2024 16:07:51 UTC používateľ Bill Cole via mailop 
 napísal:

>Who uses it?

I feel as the problem lies elsewhere. Perhaps just mentioned gigants
fails properly parse the l= tag (or even do not parse it at all) and their
UI shows whole message (or all its parts) as signed, despite that only
part of it was signed. And instead to fix that, they decided to force all
others do not use it, RFC or not RFC...

regards


-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Bill Cole via mailop]

On 2024-05-17 at 14:38:00 UTC-0400 (Fri, 17 May 2024 18:38:00 +)
Gellner, Oliver via mailop 
is rumored to have said:

While it’s not new information that the length attribute of DKIM 
poses a security risk, it’s still worthwhile to draw attention to it 
every once in a while and the usual suspects who keep on using it.


Who uses it?

I'm not seeing it at all in my recent personal "mail worth keeping" 
corpus except for one idiosyncratic case of a sender who always uses it 
with the full message length.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo@toad.social and many *@billmail.scconsult.com 
addresses)

Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Taavi Eomäe via mailop]

On 18/05/2024 01:53, Alex Liu wrote:
I dont know this is that new with regard to DMARC. missing citation: 
https://www.usenix.org/system/files/sec20-chen-jianjun.pdf


Thanks for the reference, I'll give it a read when I get the chance. 
Email is quite old by now, so the amount of resources to go through is 
rather immense.



Every a few months we see a paper / blogpost that passes SPF / DKIM / 
DMARC. So maybe requiring both SPF and DKIM for BIMI would be a good idea.


Both together might make sending a bit too error-prone. Hardening DKIM 
seems more doable. I hope that IETF's mailmaint gets to discuss topics 
like these and maybe we'll see some standardized approaches.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Alex Liu via mailop]

I dont know this is that new with regard to DMARC. missing citation:
https://www.usenix.org/system/files/sec20-chen-jianjun.pdf

It is, however, the first time someone tries to combine with BIMI.

Every a few months we see a paper / blogpost that passes SPF / DKIM /
DMARC. So maybe requiring both SPF and DKIM for BIMI would be a good idea.

On Fri, May 17, 2024 at 3:14 PM Taavi Eomäe via mailop 
wrote:

> On 17/05/2024 18:37, Slavko via mailop wrote:
>
> I didn't get what is **new** in it, nor how length of RSA keys is related...
>
> Turning the original content into a comment seemed novel to us, should in
> theory yield better forgeries than just adding new boundaries. Gmail's
> "show original" also seems to hide such comments for some reason (making it
> extra nasty).
>
>
> The l= DKIM tag was problematic in time of RFC, the Content-Type
> constructs core of message, thus have to be (over)signed already.
>
> As written, it has been known for a while. But given how prevalent it
> really is and how it has opened up new avenues of abuse, we felt it was
> time to call for some action once again.
>
>
> Best Regards
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>


-- 
Regards,
*Enze "**Alex" **Liu*
PhD Student
Department of Computer Science and Engineering
e7...@eng.ucsd.edu
University of California, San Diego
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Taavi Eomäe via mailop]

On 17/05/2024 18:37, Slavko via mailop wrote:

I didn't get what is **new** in it, nor how length of RSA keys is related...


Turning the original content into a comment seemed novel to us, should 
in theory yield better forgeries than just adding new boundaries. 
Gmail's "show original" also seems to hide such comments for some reason 
(making it extra nasty).




The l= DKIM tag was problematic in time of RFC, the Content-Type
constructs core of message, thus have to be (over)signed already.


As written, it has been known for a while. But given how prevalent it 
really is and how it has opened up new avenues of abuse, we felt it was 
time to call for some action once again.



Best Regards



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Mark E. Mallett via mailop]

On Fri, May 17, 2024 at 02:11:04PM -0700, Brandon Long via mailop wrote:
> I guess the part that's new to me is the apparent widespread (enough) use
> of the l=
> parameter.  I don't recall ever noticing its use before, though can't say
> it was ever top
> of mind when looking at various headers of messages.

I had noticed receiving some with l=1 not too long ago and went looking
and saw some others with l=0. I thought it was pretty weird, especially
the 1, but didn't record any details about it.

mm  (although it was kind of interesting that it passed)

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

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[John R Levine via mailop]

On Fri, 17 May 2024, Brandon Long wrote:
I guess the part that's new to me is the apparent widespread (enough) 
use of the l= parameter.  I don't recall ever noticing its use before, 
though can't say it was ever top of mind when looking at various headers 
of messages.


I have to admit I'm surprised too.  I thought everyone knew it was bad.

In my file of DKIM signatures in newsletter/mailing list mail I've gotten 
over the past 15 years, I have about 200,000 signatures of which 6500 have 
l=something.  I divided it in half, and since 2018 there are 98,000 
signatures of which only 500 have l=something.


It's not very common and it's gotten less common, like one message in 
2000, but it does exist.



The example in the post of someone using l=1 really sounds like a
workaround for


I looked, I see a bunch of l=1 in mailings from the libertarians at 
reason.com which makes a perverse kind of sense.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Brandon Long via mailop]

On Fri, May 17, 2024 at 1:07 PM John Levine via mailop 
wrote:

> It appears that Taavi Eomäe via mailop  said:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >Hi!
> >
> >As part of coordinated disclosure, I am sharing it here as well. In
> >short, using the approach described below, attackers can replace the
> >entire contents of a letter, in a way the letters still pass DKIM’s
> >cryptographic checks. ...
>
> There is nothing whatsoever new here.
>
> We knew l= was a bad idea when we published it, and that you could do
> all sorts of naughty things by adding or fiddling with MIME parts.
> Some loud people insisted that it would solve the mailing list
> problem, which of course it didn't, but we're stuck with it now.
>
> I suppose it couldn't hurt to remind people that using l= is a bad
> idea but if they haven't already gotten the memo sometime in the past
> decade, I wouldn't hold my breath.
>

I guess the part that's new to me is the apparent widespread (enough) use
of the l=
parameter.  I don't recall ever noticing its use before, though can't say
it was ever top
of mind when looking at various headers of messages.

The example in the post of someone using l=1 really sounds like a
workaround for
receivers requiring DKIM signing but senders having fear of messages getting
modified and rejected.  I am both in awe at the hacker make it work ethos
displayed
as well as the complete disregard for authentication.  I'm curious what
mitigation
gmail deployed short of just ignoring the l= value entirely, which would be
my
impulse though depending on how widespread it might require an annoying
amount
of outreach and rollout time to force correction.

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

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[John Levine via mailop]

It appears that Taavi Eomäe via mailop  said:
>-=-=-=-=-=-
>-=-=-=-=-=-
>Hi!
>
>As part of coordinated disclosure, I am sharing it here as well. In 
>short, using the approach described below, attackers can replace the 
>entire contents of a letter, in a way the letters still pass DKIM’s 
>cryptographic checks. ...

There is nothing whatsoever new here. 

We knew l= was a bad idea when we published it, and that you could do
all sorts of naughty things by adding or fiddling with MIME parts.
Some loud people insisted that it would solve the mailing list
problem, which of course it didn't, but we're stuck with it now.

I suppose it couldn't hurt to remind people that using l= is a bad
idea but if they haven't already gotten the memo sometime in the past
decade, I wouldn't hold my breath.

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

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Andris Reinman via mailop]

The mailauth command can detect these signatures
https://github.com/postalsys/mailauth/blob/master/cli.md

For example

$ mailauth report path-to-email.eml

"canonBodyLength": 87122,
"canonBodyLengthTotal": 87563,
"canonBodyLengthLimited": true,
"canonBodyLengthLimit": 87122,
"mimeStructureStart": 87076,


This signature uses the l-tag (canonBodyLengthLimited is true). 87122 bytes
of canonicalized body were used for the signature hash (canonBodyLength),
while the actual canonicalized body length was 87563 bytes
(canonBodyLengthTotal) and the first byte of the actual mime tree (the
first byte of the first boundary in the canonicalized body) was at 87076
bytes (mimeStructureStart) which means that only 46 bytes of the mime
structure were covered by the signature and 441 bytes were not signed at
all. So, this message content is most likely forged, and the BIMI logo
should not be displayed even though the signature is "valid".

Best regards,
Andris Reinman

Kontakt Gellner, Oliver via mailop () kirjutas kuupäeval
R, 17. mai 2024 kell 21:42:

>
> > On 17.05.2024 at 16:24 Taavi Eomäe via mailop wrote:
> >
> > Although some of these dangers have been known for a while (some parts
> are even described in the RFC itself), things like the threat landscape,
> our approach and the extent to which this can be abused have changed. In
> our opinion previously suggested and (rarely) implemented mitigations do
> not reduce these risks sufficiently.
> >
> > We hope that with some cooperation from mail operators improved defense
> measures can be implemented to strengthen DKIM for everyone.
> >
> >
> > A longer description with images is available here:
> https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/
>
> While it’s not new information that the length attribute of DKIM poses a
> security risk, it’s still worthwhile to draw attention to it every once in
> a while and the usual suspects who keep on using it.
>
> What would be interesting is a list of software that is able to ignore
> DKIM signatures which contain a length attribute and how to configure this
> behavior.
>
> —
> BR Oliver
>
> 
>
> dmTECH GmbH
> Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
> Telefon 0721 5592-2500 Telefax 0721 5592-2777
> dmt...@dm.de * www.dmTECH.de
> GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
> Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher
> 
> Datenschutzrechtliche Informationen
> Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser
> ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in
> Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder
> sich bei uns bewerben, verarbeiten wir personenbezogene Daten.
> Informationen unter anderem zu den konkreten Datenverarbeitungen,
> Löschfristen, Ihren Rechten sowie die Kontaktdaten unserer
> Datenschutzbeauftragten finden Sie hier<
> https://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832
> >.
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Gellner, Oliver via mailop]

> On 17.05.2024 at 16:24 Taavi Eomäe via mailop wrote:
>
> Although some of these dangers have been known for a while (some parts are 
> even described in the RFC itself), things like the threat landscape, our 
> approach and the extent to which this can be abused have changed. In our 
> opinion previously suggested and (rarely) implemented mitigations do not 
> reduce these risks sufficiently.
>
> We hope that with some cooperation from mail operators improved defense 
> measures can be implemented to strengthen DKIM for everyone.
>
>
> A longer description with images is available here: 
> https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/

While it’s not new information that the length attribute of DKIM poses a 
security risk, it’s still worthwhile to draw attention to it every once in a 
while and the usual suspects who keep on using it.

What would be interesting is a list of software that is able to ignore DKIM 
signatures which contain a length attribute and how to configure this behavior.

—
BR Oliver



dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Jeroen Massar via mailop]

And the reason why wanting to require both SPF _and_ DKIM passing would be a 
good thing...

Unfortunately one cannot do that.

Greets,
 Jeroen

--

> On 17 May 2024, at 16:12, Taavi Eomäe via mailop  wrote:
> 
> Hi!
> 
> As part of coordinated disclosure, I am sharing it here as well. In short, 
> using the approach described below, attackers can replace the entire contents 
> of a letter, in a way the letters still pass DKIM’s cryptographic checks. 
> This also means these forged letters can be easily replayed to reach their 
> victims. This subverts many of the expectations operators have about DKIM 
> signatures, DMARC and BIMI.
> 
> Although some of these dangers have been known for a while (some parts are 
> even described in the RFC itself), things like the threat landscape, our 
> approach and the extent to which this can be abused have changed. In our 
> opinion previously suggested and (rarely) implemented mitigations do not 
> reduce these risks sufficiently.
> 
> We hope that with some cooperation from mail operators improved defense 
> measures can be implemented to strengthen DKIM for everyone.
> 
> 
> A longer description with images is available here: 
> https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/
> 
> 
> 
> Best Regards,
> Taavi Eomäe
> Zone Media OÜ
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

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

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Slavko via mailop]

Dňa 17. mája 2024 14:12:41 UTC používateľ "Taavi Eomäe via mailop" 
 napísal:

>A longer description with images is available here: 
>https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/

I didn't get what is **new** in it, nor how length of RSA keys is related...

The l= DKIM tag was problematic in time of RFC, the Content-Type
constructs core of message, thus have to be (over)signed already.

regards


-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Marco Moock via mailop]

Am Fri, 17 May 2024 16:04:56 +0100 (BST)
schrieb Andrew C Aitchison via mailop :

> If the mail system uses a DKIM pass to show the *other pieces*
> of the message as trusted, then bad things can happen.

I don't know any end users system that shows those results to the user.
I only know MTA's filtering on that results.
Are there other cases?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Andrew C Aitchison via mailop]

On Fri, 17 May 2024, Taavi Eomäe via mailop wrote:

As part of coordinated disclosure, I am sharing it here as well. In short, 
using the approach described below, attackers can replace the entire contents 
of a letter, in a way the letters still pass DKIM’s cryptographic checks. 
This also means these forged letters can be easily replayed to reach their 
victims. This subverts many of the expectations operators have about DKIM 
signatures, DMARC and BIMI.


Although some of these dangers have been known for a while (some parts are 
even described in the RFC itself), things like the threat landscape, our 
approach and the extent to which this can be abused have changed. In our 
opinion previously suggested and (rarely) implemented mitigations do not 
reduce these risks sufficiently.


We hope that with some cooperation from mail operators improved defense 
measures can be implemented to strengthen DKIM for everyone.


A longer description with images is available here: 
https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/


Of course.
DKIM signs *pieces* of an email.

If the mail system uses a DKIM pass to show the *other pieces*
of the message as trusted, then bad things can happen.

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

[mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Taavi Eomäe via mailop]

Hi!

As part of coordinated disclosure, I am sharing it here as well. In 
short, using the approach described below, attackers can replace the 
entire contents of a letter, in a way the letters still pass DKIM’s 
cryptographic checks. This also means these forged letters can be easily 
replayed to reach their victims. This subverts many of the expectations 
operators have about DKIM signatures, DMARC and BIMI.


Although some of these dangers have been known for a while (some parts 
are even described in the RFC itself), things like the threat landscape, 
our approach and the extent to which this can be abused have changed. In 
our opinion previously suggested and (rarely) implemented mitigations do 
not reduce these risks sufficiently.


We hope that with some cooperation from mail operators improved defense 
measures can be implemented to strengthen DKIM for everyone.



A longer description with images is available here: 
https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/




Best Regards,
Taavi Eomäe
Zone Media OÜ



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop