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 DKIMs length tag and its impact on DMARC and BIMI

[Sebastian Nielsen via mailop]

That was strange, they do rewrite the sender, but doesn't resign the 
rmail.can't see headers on mobile and im currently without email client until 
Microsoft releases Office 2024 so tough they do it.@Admin [mailop-owner]: Maybe 
you should add resigning? Ergo, strip out all and any DKIM signatures, ARC 
seals and anything, and then add a DKIM signature belongning to mailop.org
 Originalmeddelande Från: Benny Pedersen via mailop 
 Datum: 2024-05-18  22:32  (GMT+01:00) Till: 
mailop@mailop.org Ämne: Re: [mailop] (Mis)use of DKIMs length tag and its 
impact on DMARC and BIMI Sebastian Nielsen via mailop skrev den 2024-05-18 
20:14:> Yeah, for mailing lists the rewrite + resign method is better, like> 
this mailing list does, rewrites everything to mailop@mailop.org> And then 
resigns the mail with their own SPF and DKIM.with this maillist does not 
doAuthentication-Results  mx.junc.eu (amavisd-new); dkim=fail (1024-bit 
key) reason="fail (message has been altered)" header.d=sebbe.euif maaillist did 
ARC first on base of dkim pass from you it would help to keep the ARC change in 
stable, this means we would all could verify you did it right in the first 
place, but if maillist screew dkim before arc-sign and arc-seal it, then there 
is only one way back to trascan :(order of things 
matter___mailop mailing 
listmailop@mailop.orghttps://list.mailop.org/listinfo/mailop___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIMs length tag and its impact on DMARC and BIMI

[Benny Pedersen via mailop]

Sebastian Nielsen via mailop skrev den 2024-05-18 20:14:

Yeah, for mailing lists the rewrite + resign method is better, like
this mailing list does, rewrites everything to mailop@mailop.org
And then resigns the mail with their own SPF and DKIM.


with this maillist does not do

Authentication-Results	mx.junc.eu (amavisd-new); dkim=fail (1024-bit 
key) reason="fail (message has been altered)" header.d=sebbe.eu


if maaillist did ARC first on base of dkim pass from you it would help 
to keep the ARC change in stable, this means we would all could verify 
you did it right in the first place, but if maillist screew dkim before 
arc-sign and arc-seal it, then there is only one way back to trascan :(


order of things matter

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

Re: [mailop] Does iCloud accept forwards?

[Bill Cole via mailop]

On 2024-05-16 at 23:40:57 UTC-0400 (Thu, 16 May 2024 20:40:57 -0700)
Mark Fletcher via mailop 
is rumored to have said:

Does the above mean that the message we sent was forwarded on from 
siark.com

to an iCloud address?


Yes. That's a SRS address. Invented and deployed to preserve viability 
of forwarding in the face of SPF.



If that's true, the envelope from and the message
from are domains other than groups.io, so why would they associate any
authentication failures to us (and start deferring email from us)?


Incompetence?


Just from the DKIM header?


That's the only obvious source, but you'd have to find out from them. 
Whatever they are doing is wrong.



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

[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 DKIMs length tag and its impact on DMARC and BIMI

[Sebastian Nielsen via mailop]

Yeah, for mailing lists the rewrite + resign method is better, like this 
mailing list does, rewrites everything to mailop@mailop.orgAnd then resigns the 
mail with their own SPF and DKIM.
 Originalmeddelande Från: Dave Crocker via mailop 
 Datum: 2024-05-18  20:02  (GMT+01:00) Till: 
mailop@mailop.org Ämne: Re: [mailop] (Mis)use of DKIMs length tag and its 
impact on DMARC and BIMI 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 CrockerBrandenburg 
InternetWorkingbbiw.netmast:@dcrocker@mastodon.social___mailop
 mailing listmailop@mailop.orghttps://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

[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