[Ietf-dkim] Re: DKIM with body length

[John Levine]

It appears that Murray S. Kucherawy   said:
>(a) Inertia will mean "l=" is generated and/or accepted for a long time to
>come no matter what we say or do; and

Yup.

>(b) Even if (a) weren't true, "l=" then becomes an unrecognized tag at
>verifiers, which will mean those signatures break and we have an
>interoperability problem (though likely a tolerable one).

It Depends(TM).  I see some mail with l=1 which means that the signature
won't verify if you ignore the l=.  But I also see a fair amount from
what appear to be Ironport appliances with the l= covering the entire
body.  If you ignore the l= you still hash the entire body, so the
signature should be OK, right?

>SHOULD be signed, and I think Content-Type was one of them; RFC 6376
>removed the explicit list in favor of more abstract guidance that should
>lead anyone toward the same original list at least.  So even that aspect of
>this attack was anticipated.

More than anticipated, explicitly described on page 41:

   If the "l=" signature tag is in use (see Section 3.5), the Content-
   Type field is also a candidate for being included as it could be
   replaced in a way that causes completely different content to be
   rendered to the receiving user.

Rather than revising 6376 I was thinking about an AS or BCP that tells
you how to make strong signatures.  Nothing exotic, use reasonbly
strong keys and sign all the headers that make sense to sign.

R's,
John

___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: DKIM with body length

[Wei Chuang]

On Mon, May 20, 2024 at 5:29 PM John Levine  wrote:

> It appears that Wei Chuang   said:
> >-=-=-=-=-=-
> >
> >Hi DKIM folks,
> >As many of you know there was a DKIM security vulnerability disclosure
> >Friday around the signature header body length tag "l=". The blog post is
> >here: https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/
> >The authors state that an adversary can append a malicious footer to a
> >message with DKIM w/body length, then rewrite the Content-type header mime
> >delimitter, that will cause the apparent body to be that of the footer but
> >will authenticate as the original DKIM signature.
>
> This exact attack is described on page 41 of RFC 6376:
>
>If the "l=" signature tag is in use (see Section 3.5), the Content-
>Type field is also a candidate for being included as it could be
>replaced in a way that causes completely different content to be
>rendered to the receiving user.
>
> There really is nothing whatsoever new here.
>
> I agree that it would be a good idea to discourage people from using
> the l= tag but first I am trying to talk to the few places that send
> me l= mail and see if I can figure out why they do it.
>
>
As the blog post authors state, the new thing is that folks are using DKIM
with body length "l=" tag.  I too was surprised to see data supporting what
the author wrote, that many many senders are signing DKIM with body
length.  While small in overall traffic volume, they are a diverse group
with many Fortune 500 companies and others with significant infrastructure
responsibilities that send messages with DKIM with body length.  Over the
last 7 days there are 71048 distinct domains that had at least one passing
DKIM signature with body length.  There is a long tail of senders with
just  a few messages of their overall traffic volume which masks their
usage, but many also send the majority of their traffic signed with body
length and thus much more easily found.
-Wei
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: DKIM with body length

[Murray S. Kucherawy]

On Sun, May 19, 2024 at 9:27 AM Wei Chuang  wrote:

> As many of you know there was a DKIM security vulnerability disclosure
> Friday around the signature header body length tag "l=". The blog post is
> here: https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/
> The authors state that an adversary can append a malicious footer to a
> message with DKIM w/body length, then rewrite the Content-type header mime
> delimitter, that will cause the apparent body to be that of the footer but
> will authenticate as the original DKIM signature.  This enables spoofing
> the original sender's identity, hence can spoof DMARC and BIMI but with a
> malicious message body.  DKIM RFC6376 section 8.2  already
> describes this problem, which the authors acknowledge, but according to
> them what is new is that there actually is mail traffic with DKIM-Signature
> w/body length which includes Fortune 500 companies.
>
> [...]
>

As everyone seems to be agreeing, there's nothing new here.  The only
concern is that people actually do use "l=" for some reason in spite of the
warnings.

There's talk here of revising RFC 6376 to remove the tag.  That's certainly
one option, and it's worth noting that we did consider doing so when RFC
4871 became RFC 6376 (STD 76), but as I recall a constraint of removing a
feature when upgrading something to Internet Standard states that the thing
you want to remove has to be unused, and "l=" was found to be in non-zero
use, so we were forced to keep it, even with the warnings.

Also, deleting it from the specification now will in my view not be much of
a solution given:

(a) Inertia will mean "l=" is generated and/or accepted for a long time to
come no matter what we say or do; and

(b) Even if (a) weren't true, "l=" then becomes an unrecognized tag at
verifiers, which will mean those signatures break and we have an
interoperability problem (though likely a tolerable one).

DKIM also warns signers to sign anything that goes to the content or
structure of the message.  RFC 4871 used to include a list of fields that
SHOULD be signed, and I think Content-Type was one of them; RFC 6376
removed the explicit list in favor of more abstract guidance that should
lead anyone toward the same original list at least.  So even that aspect of
this attack was anticipated.

It seems to me this is solved easier with local policy changes.  DKIM
allows for rejection of signatures for any local policy reason, so
operators could just start rejecting messages that use "l=" or that fail to
sign/oversign "Content-Type".  This could be an Informational document
rather than one that updates the standard.

Dave Crocker mentioned that there is a pathway to do a narrow update to the
> RFC6376 as an individual submission.  I agree that it is a good idea as
> hopefully a narrow update can be done relatively quickly.  I understand
> that body length "l=" was meant to help DKIM tolerate adding a footer
> that a mailing list might do and that there is pressure from the DMARC
> world to think about this.  Perhaps that still can be done except in a
> better secure way, and that work could be a separate document to permit it
> time to figure out how to do it.  One idea is to have the forwarder sign
> with an ARC Message-Signature and would take ownership of the new message.
> The forwarder would describe the offsets to recover the original body
> length and some receiver can validate the original DKIM signature.  Those
> offsets will also describe the forwarder's contribution to the message.
> There would also be problems around secure footer modification of
> Content-type header that are unsolved e.g. what to do if Content-type is
> oversigned.  All this work might be good candidates for the newly chartered
> Mailmaint WG.
>

Before we make suggestions about ARC, I would strongly suggest someone try
that as a solution or mitigation to this problem.  I would not like us to
publish something that shouts about this being a serious problem but then
presents untested solution(s).  And frankly, I'd like to see ARC graduate
out of Experimental status if that's what we want to put forward as a
solution.

As to MAILMAINT as a venue, we'll have to see whether the community thinks
this is "big" or "small"; if the former, it should probably get its own WG.

-MSK, presently hatless
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: DKIM with body length

[John Levine]

It appears that Wei Chuang   said:
>-=-=-=-=-=-
>
>Hi DKIM folks,
>As many of you know there was a DKIM security vulnerability disclosure
>Friday around the signature header body length tag "l=". The blog post is
>here: https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/
>The authors state that an adversary can append a malicious footer to a
>message with DKIM w/body length, then rewrite the Content-type header mime
>delimitter, that will cause the apparent body to be that of the footer but
>will authenticate as the original DKIM signature. 

This exact attack is described on page 41 of RFC 6376:

   If the "l=" signature tag is in use (see Section 3.5), the Content-
   Type field is also a candidate for being included as it could be
   replaced in a way that causes completely different content to be
   rendered to the receiving user.

There really is nothing whatsoever new here.

I agree that it would be a good idea to discourage people from using
the l= tag but first I am trying to talk to the few places that send
me l= mail and see if I can figure out why they do it.

R's,
John

___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: DKIM with body length

[Al Iverson]

On Sun, May 19, 2024 at 2:41 PM John Levine  wrote:
> Honestly, I don't know. Of the trickle of mail I see with l=, most is
> from the libertarian Reason blog with l=1 and the rest is from
> Verisign who for some reason sign with l= actual length.
>
> I suspect I could get Verisign's attention. Reason, who knows, as
> likely as not they have some political reason they think it's a good
> idea.

When this was released on Friday, I found the worst offenders I could
from own spamtrap feed, and correlated most of it to a specific email
service provider. I contacted people there on Friday and they tell me
that they are releasing a fix today (Monday). I'm light on details and
certainly can't take credit for driving this change, but yes, I think
it would be good for folks to get the attention of affected email
sending platforms as much as possible, directly if possible.

> >But there are already major mail receivers who treat any DKIM signature 
> >containing l= to be invalid.
>
> That will definitely get their attention.

I think that will convert the problem into one that email marketing
senders will understand a little more easily. Oops, why are you
treating my DKIM-signed messages as though they are not signed?

I hear whispers of more mailbox providers moving to act similarly. I
think that will help significantly.

Removing l= from the RFC still seems like a good thing, so that it
will catch up to the operational reality that large/savvy MBPs will
already be invalidating signatures containing l=, while driving the
point home for smaller providers or those who may be more of a
stickler about RFCs.

Cheers,
Al Iverson

-- 

Al Iverson // 312-725-0130 // Chicago
http://www.spamresource.com // Deliverability
http://www.aliverson.com // All about me
https://xnnd.com/calendar // Book my calendar

___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: DKIM with body length

[Steffen Nurpmeso]

Jeremy Harris wrote in
 :
 |On 19/05/2024 17:26, Wei Chuang wrote:
 |> then rewrite the Content-type header mime
 |> delimitter
 |
 |Seems like including this header in the signed set would be
 |Best Practice?

Indeed.

I want to remark that this thread seems to reiterate an attack
from 2018:

  https://noxxi.de/research/breaking-dkim-on-purpose-and-by-chance.html

It then says in "How to Fix the Problems"

  The signature itself need to include all mail headers which
  might affect the display of the message. Each of these should be
  oversigned to protect against an attacker adding extra
  headers. The headers which obviously needs to be signed are any
  headers directly displayed to the user, i.e. Subject, From, To,
  Date and Sender. Additionally any headers affecting the display
  of the message should be included, i.e. Content-Type,
  Content-Transfer-Encoding, Content-Disposition and
  Mime-Version. And there are also headers which affect the future
  message flow or how this message is displayed in the context of
  others, i.e. Reply-To, In-Reply-To and References. It might also
  be useful to add the length of the body with the 'l' attribute
  as long as all headers which might affect the display of the
  message are included in the signature and oversigned.

which is (alongside the words from RFC 6376) is why my simple
s-dkim-sign for postfix includes extended built-in lists covering
all these.

--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
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: DKIM with body length

[John Levine]

It appears that Jeremy Harris   said:
>On 20/05/2024 09:06, Alessandro Vesely wrote:
>> Content-Type: is a technical field
>
>Not a term I've met before.  Is there a formal definition?

As Dave said, no.  There isn't even an informal definition.

>And as far as "which forwarders need to change" goes -
>isn't the entire point of DKIM to detect chages?

If someone changed the Content-Type header on a message I sent,
I would certainly want the signature to break.

R's,
John

___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: WG Action: Formed Mail Maintenance (mailmaint) / Commitment

[Pete Resnick]

On 20 May 2024, at 12:55, Pete Resnick wrote:

> nobody is interested in implementing it aside from the implementer.

s/implementer/proposer (brain ahead of fingers)

-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: WG Action: Formed Mail Maintenance (mailmaint) / Commitment

[Pete Resnick]

On 20 May 2024, at 10:13, Bob Hinden wrote:

On May 19, 2024, at 7:22 PM, Dave Crocker  wrote:

On 5/10/2024 2:33 PM, Dave Crocker wrote:

On 5/10/2024 10:54 AM, Murray S. Kucherawy wrote:
* Prior to accepting any Standards Track document for development, 
there must be a commitment to implement the resulting proposed 
standard from at least two independent parties, as recorded on a 
related IETF mailing list.


Just realized this concern did not get attention:

Simply put this is a thoroughly unreasonable burden.


I disagree.


Companies don't work that way.


That's an overly broad universal statement.

Companies do not make public, future commitments for implementing 
standards.  And when there are attempts to get them to, they waffle 
and evade.


Some do, some don't. We've had experience in the email community where 
people participate quite openly, show up for the hackathon with example 
code, and discuss their implementation plans quite openly. We've also 
had experience where (mostly large) companies do exactly what you 
describe. The requirement is not that all participants in the WG make a 
commitment to implement; just two or more.


Also, I believe, the IETF has wisely never tried to impose this 
burden.


I regularly hear the question posed in BOFs. Perhaps that's just 
lip-service, but it's certainly being taken into consideration. And I 
think it is a perfectly wise thing to impose, particularly in a space 
where we've seen multiple proposals over the years that individuals 
bring to WGs, get large amounts of input and direction, only to discover 
that nobody is interested in implementing it aside from the implementer.


Again, if the goal is to limit this working group to only take on 
specifications that are already in use, then just say that.   It's 
simpler, clearer, more direct and, frankly, more pragmatic.


That is not the intention as far as I understand it, and in fact it is 
something that I would rather see us decrease or eliminate rather than 
encourage. If people want to work on specifications outside of the IETF, 
they should publish them outside of the IETF. We have seen the ill 
effects of bringing in work that is mostly or completely "done". And 
there is IMO no reasonable way to truly assess the IETF consensus for 
work that is mostly or completely done outside of the IETF.



Because that is the practical effect of what's in the charter.


To further Dave’s points, “implementation” is not the same as 
deploying it operationally at scale.  That would be a significant 
commitment for someone to make.


Actually, that seems to be *opposed* to Dave's points rather than 
furthering them: Deploying at scale *would* be too significant a 
commitment to make. Implementation is not, at least for some folks.


pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: WG Action: Formed Mail Maintenance (mailmaint) / Commitment

[Bob Hinden]

Hi,

> On May 19, 2024, at 7:22 PM, Dave Crocker  wrote:
> 
> On 5/10/2024 2:33 PM, Dave Crocker wrote:
>> On 5/10/2024 10:54 AM, Murray S. Kucherawy wrote:
>>> * Prior to accepting any Standards Track document for development, there 
>>> must 
>>> be a commitment to implement the resulting proposed standard from at least 
>>> two independent parties, as recorded on a related IETF mailing list.

To further Dave’s points, “implementation” is not the same as deploying it 
operationally at scale.  That would be a significant commitment for someone to 
make.  

 Bob

> Just realized this concern did not get attention:
> 
> Simply put this is a thoroughly unreasonable burden.  
> 
> Companies don't work that way.
> 
> Companies do not make public, future commitments for implementing standards.  
> And when there are attempts to get them to, they waffle and evade.
> 
> Also, I believe, the IETF has wisely never tried to impose this burden.
> 
> Again, if the goal is to limit this working group to only take on 
> specifications that are already in use, then just say that.   It's simpler, 
> clearer, more direct and, frankly, more pragmatic.
> 
> Because that is the practical effect of what's in the charter.
> 
> d/
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> mast:@dcrocker@mastodon.social 
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: DKIM with body length

[Dave Crocker]

On 5/20/2024 2:23 AM, Jeremy Harris wrote:

And as far as "which forwarders need to change" goes -
isn't the entire point of DKIM to detect chages?


no.

"Abstract

   DomainKeys Identified Mail (DKIM) permits a person, role, or
   organization that owns the signing domain to claim some
   responsibility for a message by associating the domain with the
   message. "

RFC 6376: DomainKeys Identified Mail (DKIM) Signatures <#>

 https://www.rfc-editor.org/rfc/rfc6376.html 



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: DKIM with body length

[Jeremy Harris]

On 20/05/2024 09:06, Alessandro Vesely wrote:

Content-Type: is a technical field


Not a term I've met before.  Is there a formal definition?

And as far as "which forwarders need to change" goes -
isn't the entire point of DKIM to detect chages?
--
Cheers,
  Jeremy

___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: DKIM with body length

[Alessandro Vesely]

On Sun 19/May/2024 21:28:21 +0200 Jeremy Harris wrote:

On 19/05/2024 17:26, Wei Chuang wrote:

then rewrite the Content-type header mime delimiter


Seems like including this header in the signed set would be 
Best Practice?



I hope not.  Content-Type: is a technical field, which forwarders need to 
change, for consistency, if they apply even slightly changes to the body. 
Signing it hinders the possibility to verify the signature after heuristically 
removing the footer.


What should be Best Practice is not using l=.


Best
Ale
--



___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org