[Ietf-dkim] Re: DKIM with body length

[Alessandro Vesely]

On Wed 29/May/2024 19:22:54 +0200 John Levine wrote:

It appears that Alessandro Vesely   said:
I did try and use it.  You have to be careful to put the subject tag on new 
messages or write /Re:/ in the right place.  You must not sign MIME-Version: 
and other fields that the MLM writes anew (yes, also Content-Type:).  Oh, and 
never send multipart (HTML) messages.  With such limitations, l= does sometimes 
deliver enough robustness for a signature to survive through a MLM.  Unless the 
MLM transforms the whole stuff to base64, that is.


Or it changes the MIME boundary string, or it puts text at the front 
of the body, or it changes the subject or any of the other signed 
headers, or it does any of a hundred other things that lists do.



Yes, I didn't mean to be exhaustive.  I only recounted my experience when I did 
try it, on this list in 2011.



There are certainly some cases where a signature with l= will still be 
valid after the message goes through a list, but it's unpredictable 
and fragile so no sensible person would count on it.



That's more or less what I wrote.


Best
Ale
--



___
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 Alessandro Vesely   said:
>I did try and use it.  You have to be careful to put the subject tag on new 
>messages or write /Re:/ in the right place.  You must not sign MIME-Version: 
>and other fields that the MLM writes anew (yes, also Content-Type:).  Oh, and 
>never send multipart (HTML) messages.  With such limitations, l= does 
>sometimes 
>deliver enough robustness for a signature to survive through a MLM.  Unless 
>the 
>MLM transforms the whole stuff to base64, that is.

Or it changes the MIME boundary string, or it puts text at the front
of the body, or it changes the subject or any of the other signed
headers, or it does any of a hundred other things that lists do.

There are certainly some cases where a signature with l= will still be
valid after the message goes through a list, but it's unpredictable
and fragile so no sensible person would count on it.

Can we agree that l= was a mistake that should go away and worry about
something else, please?

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

[Alessandro Vesely]

On Tue 28/May/2024 21:08:26 +0200 Hector Santos wrote:

On May 25, 2024, at 12:49 PM, John R Levine  wrote:
On Fri, 24 May 2024, Jon Callas wrote:

1) It appears that the issue with l= is that implementers are not doing it 
correctly, ...


If there ever was a correct way to use l=, there sure isn't now.  But per 
your next message we seem to agree on the outcome.


Yet, as shown, there are many implementations that support it for usage 
(outbound) and ignoring (inbound) per the consensus.   I did agree with the 
option and left it as option for sysops to enable/disable.   But I agree it was 
not an answer to restoring original verification and can be a loop hole.



I did try and use it.  You have to be careful to put the subject tag on new 
messages or write /Re:/ in the right place.  You must not sign MIME-Version: 
and other fields that the MLM writes anew (yes, also Content-Type:).  Oh, and 
never send multipart (HTML) messages.  With such limitations, l= does sometimes 
deliver enough robustness for a signature to survive through a MLM.  Unless the 
MLM transforms the whole stuff to base64, that is.



Best
Ale
--



___
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

[Hector Santos]

> On May 25, 2024, at 12:49 PM, John R Levine  wrote:
> 
> On Fri, 24 May 2024, Jon Callas wrote:
>>> blank lines.) Maybe you can tell it's from a list and the crud is
>>> benign, or maybe you can't and you should treat it as suspicious.
>> 
>> And yet, I didn't make up the word robustness, it's there in the spec as 
>> Dave quoted.
> 
> When I read the whole paragraph, the message I get is that l= is intended to 
> survive mailing lists but it has many problems so don't use it.  My 
> recollection is that for a few features like l=, most of us found them 
> useless, a few people really really wanted them, so that paragraph was a way 
> to get the document out the door.
> 
> Twenty years ago there was no DMARC* and the issue was that until DKIM became 
> more widely used, mail from dusty lists would have no signatures at all.  In 
> fact lists did start signing pretty quickly, list mail all has DKIM 
> reputation and that particular issue is moot.
> 
> I do not ever recall l= being an proposed as an invitation to recipient 
> systems to do surgery on incoming mail.  If anyone had ever suggested that, 
> I'm sure I'm not the only list manager who would have been sure to strip any 
> l= signatures to prevent downstream funny business.
> 
>> 1) It appears that the issue with l= is that implementers are not doing it 
>> correctly, ...
> 
> If there ever was a correct way to use l=, there sure isn't now.  But per 
> your next message we seem to agree on the outcome.

Yet, as shown, there are many implementations that support it for usage 
(outbound) and ignoring (inbound) per the consensus.   I did agree with the 
option and left it as option for sysops to enable/disable.   But I agree it was 
not an answer to restoring original verification and can be a loop hole.   

All the best,
Hector Santos



___
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

[Jon Callas]

> On May 25, 2024, at 09:49, John R Levine  wrote:
> 
> On Fri, 24 May 2024, Jon Callas wrote:
>>> blank lines.) Maybe you can tell it's from a list and the crud is
>>> benign, or maybe you can't and you should treat it as suspicious.
>> 
>> And yet, I didn't make up the word robustness, it's there in the spec as 
>> Dave quoted.
> 
> When I read the whole paragraph, the message I get is that l= is intended to 
> survive mailing lists but it has many problems so don't use it.  My 
> recollection is that for a few features like l=, most of us found them 
> useless, a few people really really wanted them, so that paragraph was a way 
> to get the document out the door.

Well --- kinda? It's really hard to discuss "mailing list" as if it's a thing. 
For example, there's Mailman (and there's a lot of crap in Mailman that is 
related to how to do a mailing list in a world of signed messages) which is 
very different thing from say, Google Groups, which is a very different thing 
from (handwave) an exploder similar to what happens in virtual entry in Postfix.

Certainly, it's common (perhaps expected) that a mailing list will add a 
trailer to a message. However, that's not the only thing a mailing list does, 
and I don't want to go down that rathole in this thread. I'm happy to go down 
it in another thread.

Lots of business mail has (or had) trailers put on them to declare that 
scanning had been done, or bogus legal threats, or many other things. The 
intent of l= was for the administrative domain to make an affirmative statement 
about the content they are willing to be responsible for.  


> I do not ever recall l= being an proposed as an invitation to recipient 
> systems to do surgery on incoming mail.  If anyone had ever suggested that, 
> I'm sure I'm not the only list manager who would have been sure to strip any 
> l= signatures to prevent downstream funny business.

Well, I do. As I said, it's the thing that turned me from being bewildered by 
it to thinking it was a good idea. It's why I remember it. I think there needs 
to be more surgery on emails in a number of places, but that too is a side 
discussion. (Among others, Received: headers.)

> 
>> 1) It appears that the issue with l= is that implementers are not doing it 
>> correctly, ...
> 
> If there ever was a correct way to use l=, there sure isn't now.  But per 
> your next message we seem to agree on the outcome.

Yes, I was thinking about it and was reminded by advice of an old boss/mentor 
not to confuse the world one is in with the world one wants to see. Also 
another situation where an idea that would have been a good one if implemented 
correctly was implemented badly, so we removed it from the -bis on that.

Jon


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

On Fri, 24 May 2024, Jon Callas wrote:

blank lines.) Maybe you can tell it's from a list and the crud is
benign, or maybe you can't and you should treat it as suspicious.


And yet, I didn't make up the word robustness, it's there in the spec as Dave 
quoted.


When I read the whole paragraph, the message I get is that l= is intended 
to survive mailing lists but it has many problems so don't use it.  My 
recollection is that for a few features like l=, most of us found them 
useless, a few people really really wanted them, so that paragraph was a 
way to get the document out the door.


Twenty years ago there was no DMARC* and the issue was that until DKIM 
became more widely used, mail from dusty lists would have no signatures at 
all.  In fact lists did start signing pretty quickly, list mail all has 
DKIM reputation and that particular issue is moot.


I do not ever recall l= being an proposed as an invitation to recipient 
systems to do surgery on incoming mail.  If anyone had ever suggested 
that, I'm sure I'm not the only list manager who would have been sure to 
strip any l= signatures to prevent downstream funny business.



1) It appears that the issue with l= is that implementers are not doing it 
correctly, ...


If there ever was a correct way to use l=, there sure isn't now.  But per 
your next message we seem to agree on the outcome.


R's,
John

* - nobody used ADSP

___
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

[Jon Callas]

I was thinking about this, and have come around to the other side -- if the 
real-world problem is that people are doing a feature wrong, pulling it is a 
completely reasonable response. That it could be a good idea, if only it were 
implemented right doesn't matter. The reality is that it's wrong in the real 
world. So put me down on the side of just axing it.

Jon

___
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

[Jon Callas]

> On May 24, 2024, at 19:55, John Levine  wrote:
> 
> It appears that Jon Callas   said:
>> And look at it -- l= is intended to increase robustness and strictness of 
>> interpreting the message.
> 
> I don't see how that followes. In all the years I've been futzing with
> email I can't ever think of a time where a message showed up with
> added crud at the end and the right thing to do was to discard the
> crud and keep going. (I'm ignoring the old sendmail bug that added
> blank lines.) Maybe you can tell it's from a list and the crud is
> benign, or maybe you can't and you should treat it as suspicious.

And yet, I didn't make up the word robustness, it's there in the spec as Dave 
quoted.

> 
> The rationale I recall for l= is that it would let mailing lists put a
> footer on messages. That never seemed very persuasive, both because
> lists make a lot of other changes to messages, and because it opens up
> a hole you can drive an ocean liner throught.

And also lots of other trailers, like AV scanners, and so on. For mailing 
lists, there are plenty of other issues, too, and let's not get into that, as 
it's a mess that's orthogonal to this discussion.

> 
> I also recall people claiming with a straight face that MUAs would
> show the signed and unsigned parts of a message in different colors so
> the user could decide which parts of it to believe. I hope I don't
> have to explain why that was a terrible idea.

You don't, at least not to me. I think it's a horrible idea, too. The Yahoo 
guys considered it, and I vaguely remember there was some mail client that did 
it once. 

The bottom line for me is twofold:

1) It appears that the issue with l= is that implementers are not doing it 
correctly, and that there's even lazy-unto-hostile use of it. If this is the 
case, that implementers are not doing the spec properly, I don't see that 
changing the spec is going to fix the issue, that of implementers not doing the 
spec.

2) If we get a couple implementers to lean hard in the other direction -- an 
anti-Postel's Law if you were, be conservative in what you generate and really 
obsessive about compliance on receipt -- then it wouldn't need to be changed in 
the spec.

I was originally against it because I thought it would be hinkey in ways not 
dissimilar to the way it's got issues today. I was convinced that it was a good 
idea if it were implemented well, which it's not. At the end of the day, 
implementers have to either implement it right or not at all. I'm on board with 
that. Removing it from the spec is a fine way to address the problem, providing 
that we end up with implementers implement not doing it correctly. 

I still think that implementers implementing it correctly is a better solution 
than implementers removing it correctly, in part because removing it correctly 
means handling some error condition when it's there (unless we agree that 
ignoring it is fine).

Jon


___
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 Jon Callas   said:
>And look at it -- l= is intended to increase robustness and strictness of 
>interpreting the message.

I don't see how that followes. In all the years I've been futzing with
email I can't ever think of a time where a message showed up with
added crud at the end and the right thing to do was to discard the
crud and keep going. (I'm ignoring the old sendmail bug that added
blank lines.) Maybe you can tell it's from a list and the crud is
benign, or maybe you can't and you should treat it as suspicious.

The rationale I recall for l= is that it would let mailing lists put a
footer on messages. That never seemed very persuasive, both because
lists make a lot of other changes to messages, and because it opens up
a hole you can drive an ocean liner throught.

I also recall people claiming with a straight face that MUAs would
show the signed and unsigned parts of a message in different colors so
the user could decide which parts of it to believe. I hope I don't
have to explain why that was a terrible idea.

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

[Dave Crocker]

On 5/24/2024 5:11 PM, Jon Callas wrote:
You are indeed being finicky, as well as correct. I wasn't talking 
about the approved RFC, but the discussion around it.


Well, it is indeed common for people to assert this kind of semantic, 
independent of the spec.  The only problem with that is when someone 
tries to follow the spec and doesn't conform to the unstated semantic.  
It's a small matter of interoperability. Hence my finickiness.



Nonetheless, I think the essence of that discussion and my comments 
are embodied in:
8.2 . 
Misuse of Body Length Limits ("l=" Tag)


Use of the "l=" tag might allow display of fraudulent content without
appropriate warning to end users.  The "l=" tag is intended for
increasing signature robustness when sending to mailing lists that
both modify their content and do not sign their modified messages.
And look at it -- l= is intended to increase robustness and strictness 
of interpreting the message.


What's unusual about DKIM is that the crypto is used as a kind of glue, 
to affix the d= name.  Robustness essentially refers to a strength of 
the glue.  Alas, l= makes the glue weaker, rather than the originally 
intended stronger (ie, survivable when transiting a mailing list.


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

[Jon Callas]

> Jon,
> 
> Sorry to be finicky, but I don't recall any statement in the DKIM 
> specification that matches or approximate that semantic for any aspect of 
> DKIM, never mind l=.
> 
> As for l= semantics, this is all of the relevant text, none of which is 
> nearly as interesting as the interpretation you've invoked:
> 
You are indeed being finicky, as well as correct. I wasn't talking about the 
approved RFC, but the discussion around it.

Nonetheless, I think the essence of that discussion and my comments are 
embodied in:
>> 8.2 .  Misuse of 
>> Body Length Limits ("l=" Tag)
>> 
>>Use of the "l=" tag might allow display of fraudulent content without
>>appropriate warning to end users.  The "l=" tag is intended for
>>increasing signature robustness when sending to mailing lists that
>>both modify their content and do not sign their modified messages.

And look at it -- l= is intended to increase robustness and strictness of 
interpreting the message.

Jon



___
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/24/2024 4:38 PM, Jon Callas wrote:

"well, I attest to generating this message, but only the first 1234 bytes of it, 
after that, well -- you're on your own."



Jon,

Sorry to be finicky, but I don't recall any statement in the DKIM 
specification that matches or approximate that semantic for any aspect 
of DKIM, never mind l=.


As for l= semantics, this is all of the relevant text, none of which is 
nearly as interesting as the interpretation you've invoked:




l= Body length count (plain-text unsigned decimal integer; OPTIONAL,
   default is entire body).  This tag informs the Verifier of the
   number of octets in the body of the email after canonicalization
   included in the cryptographic hash, starting from 0 immediately
   following the CRLF preceding the body.
...



and:

8.2 . Misuse 
of Body Length Limits ("l=" Tag)


Use of the "l=" tag might allow display of fraudulent content without
appropriate warning to end users.  The "l=" tag is intended for
increasing signature robustness when sending to mailing lists that
both modify their content and do not sign their modified messages.


and:

Appendix D . 
MUA Considerations (INFORMATIVE)


...
   If the message has an "l=" tag whose value does not
extend to the end of the message, the MUA might also hide or mark the
portion of the message body that was not signed.


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

[Jon Callas]

I feel like I ought to comment. I've always had mixed emotions about l=, and I 
also agree with some of the things John Levine said.

When we first talked about l=, I thought it was kinda silly. What brought me 
around to it was a comment someone made that the receiver of a message with l= 
ought to cut the message at the end of l= and just drop all message content 
after that. With that observation, I turned around. The silly thing about was 
that it was essentially the statement by the authoritative domain, "well, I 
attest to generating this message, but only the first 1234 bytes of it, after 
that, well -- you're on your own." And this is indeed a silly thing. Why attest 
to a part of the message? However, once one looks at this and decides that the 
remaining characters ought to go into the bit bucket, it makes sense. 

When the sender is using l= to tell you they're only signing that, they're also 
saying that the tail end of the message is detritus or even passive forgery. 
That trailer really ought to go. We have a signed statement that it's not part 
of the message, after all. Now, all of a sudden it made sense to me. I even got 
excited about it. It has real meaning. (Now, one could also argue that without 
l= an MTA oughta chuck any unsigned parts of the message, as well, but let's 
not go there quite at this moment.)

John Levine pointed out two important things: that the issues with l= stem from 
its misuse, not its use (and often misuse that is in violation of the 
standard), and also that we can't expect that people who are not following the 
standard are suddenly going to start following the standard if we change it. 
Each of these are important things to discuss.

Let's take the case of someone who stupidly signed a message with l= and a 
small number, thus permitting a spammer to put actual bad stuff at the end (and 
not just an irrelevancy like whose antivirus product is failing to flag the 
malware in it). If a receiving MTA cut off the message at the end of l=, not 
only would this eliminate the bad content, it would deliver a message that 
would very likely look strange or bogus to the human who looked at it. "WTF, 
this message cuts off after only 12 characters -- huh, I guess I'll delete it."

If software did this -- actually implemented what l= says (albeit passively, 
not actively) that the message is only N bytes long -- then the problem would 
go away, and this is a *better* solution than getting rid of l=.

Now let me get to John's very important point. A standard is a description. 
It's almost like a grammar. It's a way that an implementor can use to know that 
if they want to express a concept X, they should lay out the bytes in that 
standard's form. At the same time, it says to the receiving implementor that 
when someone says X, here's what they were trying to say.

If someone is not emitting a message according to the standard, then our 
changing the standard is rather like a photo of a gravestone I saw last week 
that read, "Here lies (not LAYS) ..." of an English teacher. My comment was 
that although I'm a descriptivist, I stan the message.

That is relevant to us, because much of the discussion -- and John's point -- 
is that if implementors are not doing what the standard says (let alone things 
it implies), no amount of changing the standard is going to do something. Heck, 
we might as well put l= on DKIMs gravestone.

Secondarily, implementors have a lot of leeway in what they do. There's nothing 
wrong with (also mentioned as a thing some people do) to consider wacky use of 
l= to be a sign that it's spam and just toss it. Moreover, that apparently got 
people to fix their code. 

From a standards and implementation standpoint, the best fix to this situation 
is not to get rid of l= as that's letting the shoddy implementors win. The best 
fix is for implementors to double down on l= and interpret it in the way that I 
think is the best way. If there's an l=, then drop everything afterwards. (Note 
that one could also implement this concept passively -- excising unsigned 
content from a message in a lot of places. If someone did it, it's outside the 
standard anyway, and would be a Good Thing for the integrity of the email 
ecosystem.)

Summing up: I completely agree with John's real point. If people aren't 
following the standard, you aren't going to fix that by changing the standard, 
no matter what change you make. Secondarily, I think that a better fix for this 
situation to strictly interpret l= than get rid of it because a strict 
interpretation leads to messages being delivered to humans that are exactly 
what was said, but not what was meant. Make them say what they mean and mean 
what they say.

Jon



___
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

[Emil Gustafsson]

+1 to Scott's comment (killing l= in the simplest possible way).

I don't think that change necessarily will drive senders to change their
implementations (as we're already seeing some stop using l= already), but I
think it makes sense to have the RFC take a stronger stance and outright
remove support for l= over just calling out the risks with using it.

/E

On Fri, May 24, 2024 at 4:14 PM John R Levine  wrote:

> According to Scott Kitterman  :
> >Honestly, I think l= is an idea whose time has passed (if it ever existed
> at all).  We ought to just kill it using the simplest
> >procedural mechanism available.
>
> We can do an update to deprecate l= but I think that if we just adjusted
> our validation software to ignore l= the failure rate would be vanishingly
> low.
>
> The ESP that was using l=1 has stopped. Ironport systems sign the entire
> body and set l= to the body length, so even if you ignore the l=, the
> signature on an unmodified message will still validate.
>
> R's,
> John
>
> ___
> Ietf-dkim mailing list -- ietf-dkim@ietf.org
> To unsubscribe send an email to ietf-dkim-le...@ietf.org
>
___
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 R Levine]

According to Scott Kitterman  :

Honestly, I think l= is an idea whose time has passed (if it ever existed at 
all).  We ought to just kill it using the simplest
procedural mechanism available.


We can do an update to deprecate l= but I think that if we just adjusted 
our validation software to ignore l= the failure rate would be vanishingly 
low.


The ESP that was using l=1 has stopped. Ironport systems sign the entire 
body and set l= to the body length, so even if you ignore the l=, the 
signature on an unmodified message will still validate.


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

[Alessandro Vesely]

On Thu 23/May/2024 20:13:07 +0200 John Levine wrote:

I guess this isn't as obvious as the authors of 6376 thought since we still
have at least one person on this list insisting that you don't need to sign C-T.



It's ill-conditioned to use l=.  Not signing C-T is fine.


Best
Ale
--




___
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

[Scott Kitterman]

On May 23, 2024 6:13:07 PM UTC, John Levine  wrote:
>It appears that Murray S. Kucherawy   said:
>>I've read the middle part a few times and I don't understand either the
>>attack or the proposed mitigation, so I think some examples might help.
>
>The attack requires l= and an unsigned Content-Type header.
>
>If Content-Type isn't signed, the bad guy can change the part boundary
>string and then add new parts with the new boundary at the end. The
>entire original message, which is all that the l= covers, is ignored
>as junk before the first boundary.
>
>I guess this isn't as obvious as the authors of 6376 thought since we still
>have at least one person on this list insisting that you don't need to sign 
>C-T.
>
>On the other hand, I see that the perl and python DKIM modules sign
>the MIME Content-* headers by default. Do you remember what opendkim
>does? A quick look at the code wasn't too enlightening.
>
>Requiring that the l= cover some minimum percentage of the message is
>helpful but not that helpful, since you could add a short part with a
>phish URL to a long message and probably still pass the percent rule.
>
>On the third hand, I'm looking at mail in the IETF archives from
>Verisign which has had DKIM signatures the l= tag since shortly after
>the time they switched from Google to Ironport in late 2016. The set
>of headers it signs is inconsistent. It always includes MIME-Version,
>sometimes Content-Transfer-Encoding, and never Content-Type. So we do
>have at least some examples where this bug exists.
>
For the Python module, my recollection is that I stared at RFC 6376, Section 
5.4.1 and made the default set of header fields what it looked to me like the 
document recommended.  I assume that since defaults are set before we know 
anything about the message to be signed, I included Content-Type since there's 
no way to know at that point if there will be an l= in the signature or not.

I'm confident I considered it enough of a corner case not to be worth adding 
complexity for.



Honestly, I think l= is an idea whose time has passed (if it ever existed at 
all).  We ought to just kill it using the simplest procedural mechanism 
available.

Scott K

___
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 Thu, May 23, 2024 at 11:13 AM John Levine  wrote:

> On the other hand, I see that the perl and python DKIM modules sign
> the MIME Content-* headers by default. Do you remember what opendkim
> does? A quick look at the code wasn't too enlightening.
>

It signs them all unless you configure it to sign only specific ones.

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

A. Schulze wrote in
 :
 |Am 23.05.24 um 20:13 schrieb John Levine:
 |> Do you remember what opendkim does? A quick look at the code wasn't \
 |> too enlightening.
 |
 |OpenDKIM sign 'from' and this set of header without further configuration:
 |https://github.com/trusteddomainproject/OpenDKIM/blob/master/libopendkim\
 |/dkim.c#L221-L245
 |
 |I've these two settings:
 |SignHeaders csl:*,+autocrypt,+content-transfer-encoding,+content-typ\
 |e,+message-id,+mime-version,+openpgp,+resent-message-id
 |OversignHeaders csl:autocrypt,cc,content-transfer-encoding,content-type,\
 |date,from,in-reply-to,message-id,mime-version,openpgp,references,subject,to
 |
 |https://manpages.debian.org/bookworm/opendkim/opendkim.conf.5.en.html#Si\
 |gnHeaders
 |https://manpages.debian.org/bookworm/opendkim/opendkim.conf.5.en.html#Ov\
 |ersignHeaders
 |
 |since years no (known) issues ...

One needs specific sets for personal email or when driving
a mailing-list, at least for the oversigning (that i call
sealing); i document the sealing built-in list (for my one) like

 Remarks: In order not to break mailing-list posts (handled by
 software which does not recognize message signatures) the built-
 in defaults exclude ‘Reply-To’ and all the mailing-list related
 fields of RFC 2369.  In order to ease DKIM signing for mailing-
 lists as such sealing provides another built-in default, ad‐
 dressable via plus sign ‘+’.

Only to mention it.

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

[Steffen Nurpmeso]

Wei Chuang wrote in
 :

Just to note again that this reiterates an attack from 2018.

  
https://mailarchive.ietf.org/arch/msg/ietf-dkim/S3gLEswN9pz2Qd_cLZRWrsZ_oo4/bod

It was for example discussed on the exim list in 2019

  https://lists.exim.org/lurker/message/20190430.030725.d35d9752.da.html

Funnily that is surrounded by a thread

  Re: [exim-dev] Mailop list: exim and google fighting over DKIM

Well, then...

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

On Thu, 23 May 2024, Philip Guenther wrote:

I said "this current round of visibility", a statement which implies
_previous_ rounds of visibility of a NOT NEW thing.


Sorry, I don't understand what you think is invisible here.


I think it could be useful to leverage the current round of publicity to
fix more than the specific problem, but it sounds like you believe that's
a lost cause and reiterating advice is ineffective.  Oh well.


General advice to the world, nope.  Identifying specific senders with the 
l= problem has been quite effective.  We've found an ESP who was signing 
with l=1 and has now stopped.  It appears that a lot of the others have 
poorly configured Ironport devices so who do we know at Ironport?


By the way, I see from IETF mailing list logs that Ironport users have 
been signing with l= and no Content-Type for most of a decade and nobody 
has noticed until now.


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

[Philip Guenther]

On Thu, 23 May 2024, John R Levine wrote:
> On Thu, 23 May 2024, Philip Guenther wrote:
...
> > This current round of visibility on risks of the l= tag and not signing
> > content-type is a moment where *signers* are being prodded and updating
> > their configurations. ,,,
> 
> For about the tenth time, this particular issue is specifically called out 
> in RFC 6376.  It is not new, <...>

If you're going to respond then I ask you respond to what I wrote and not 
something I didn't.

Did I say it's new?  No.

I said "this current round of visibility", a statement which implies 
_previous_ rounds of visibility of a NOT NEW thing.


I think it could be useful to leverage the current round of publicity to 
fix more than the specific problem, but it sounds like you believe that's 
a lost cause and reiterating advice is ineffective.  Oh well.


Philip

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

On Thu, 23 May 2024, Philip Guenther wrote:

** or don't over-sign and clients use the first found...


I would prefer not to go there.  A message with two Content-Type headers
or two Subject headers or Date or Message-ID and so forth is not a valid
message, and a DKIM signer or validator should just say no.


I'm not familiar with DKIM validators that also apply those sorts of "too
many instances of a field" rules.  Perhaps it would make sense to talk
about that in a revision of the DKIM rfc, ...


More than a decade ago Doug Otis went on endlessly about adding an extra 
subject line, which indeed in some cases would get past a DKIM validator, 
and pretty much randomly MUAs might show one subject or the other.  You 
can do much more effective filtering by assuming defective messages are 
spam, which they invariably are, rather than screwing around with 
signatures on them.



This current round of visibility on risks of the l= tag and not signing
content-type is a moment where *signers* are being prodded and updating
their configurations. ,,,


For about the tenth time, this particular issue is specifically called out 
in RFC 6376.  It is not new, it is not interesting beyond noticing that a 
trickle of signers still get it wrong.  If people don't read the spec, 
there's not much we can do about 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

[A. Schulze]

Am 23.05.24 um 20:13 schrieb John Levine:

Do you remember what opendkim does? A quick look at the code wasn't too 
enlightening.


OpenDKIM sign 'from' and this set of header without further configuration:
https://github.com/trusteddomainproject/OpenDKIM/blob/master/libopendkim/dkim.c#L221-L245

I've these two settings:
SignHeaders 
csl:*,+autocrypt,+content-transfer-encoding,+content-type,+message-id,+mime-version,+openpgp,+resent-message-id
OversignHeaders 
csl:autocrypt,cc,content-transfer-encoding,content-type,date,from,in-reply-to,message-id,mime-version,openpgp,references,subject,to

https://manpages.debian.org/bookworm/opendkim/opendkim.conf.5.en.html#SignHeaders
https://manpages.debian.org/bookworm/opendkim/opendkim.conf.5.en.html#OversignHeaders

since years no (known) issues ...

Andreas

___
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

[Philip Guenther]

On Thu, 23 May 2024, John R Levine wrote:
> On Thu, 23 May 2024, Philip Guenther wrote:
> > There's a related, though much less general, attack that works even if you
> > don't use the l= tag: on a message which has nested multiparts, there are
> > multiple potential delimiters that will look legit to a MIME parser, so if
> > you don't sign Content-Type** then an attacker can change the delimiter
> > from the outermost to a inner delimiter and make it appear that the sender
> > directly sent just that inner content, possibly resulting in
> > misattribution.
> >
> > ** or don't over-sign and clients use the first found...
> 
> I would prefer not to go there.  A message with two Content-Type headers 
> or two Subject headers or Date or Message-ID and so forth is not a valid 
> message, and a DKIM signer or validator should just say no.

I'm not familiar with DKIM validators that also apply those sorts of "too 
many instances of a field" rules.  Perhaps it would make sense to talk 
about that in a revision of the DKIM rfc, bringing it to the attention of 
those writing validators that enforcing those limits for any signed 
headers may be necessary in order for the DKIM signature to actually 
protect what people expect it to protect, given the many clients which do 
*not* enforce those limits.

This current round of visibility on risks of the l= tag and not signing 
content-type is a moment where *signers* are being prodded and updating 
their configurations.  For those signers who don't want to wait until all 
their recipients' validators are updated, oversigning is an option to get 
protection now.


Philip Guenther

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

On Thu, 23 May 2024, Philip Guenther wrote:

There's a related, though much less general, attack that works even if you
don't use the l= tag: on a message which has nested multiparts, there are
multiple potential delimiters that will look legit to a MIME parser, so if
you don't sign Content-Type** then an attacker can change the delimiter
from the outermost to a inner delimiter and make it appear that the sender
directly sent just that inner content, possibly resulting in
misattribution.

** or don't over-sign and clients use the first found...


I would prefer not to go there.  A message with two Content-Type headers 
or two Subject headers or Date or Message-ID and so forth is not a valid 
message, and a DKIM signer or validator should just say no.


Before anyone mentions the robustness principle, it says to be liberal 
*where the spec is ambiguous" which it is not here, and to be prepared

to recognize and reject garbage that doesn't meet the spec.

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

[Philip Guenther]

On Thu, 23 May 2024, John Levine wrote:
> It appears that Murray S. Kucherawy   said:
> >I've read the middle part a few times and I don't understand either the
> >attack or the proposed mitigation, so I think some examples might help.
> 
> The attack requires l= and an unsigned Content-Type header.
> 
> If Content-Type isn't signed, the bad guy can change the part boundary
> string and then add new parts with the new boundary at the end. The
> entire original message, which is all that the l= covers, is ignored
> as junk before the first boundary.

There's a related, though much less general, attack that works even if you 
don't use the l= tag: on a message which has nested multiparts, there are 
multiple potential delimiters that will look legit to a MIME parser, so if 
you don't sign Content-Type** then an attacker can change the delimiter 
from the outermost to a inner delimiter and make it appear that the sender 
directly sent just that inner content, possibly resulting in 
misattribution.


** or don't over-sign and clients use the first found...



> On the other hand, I see that the perl and python DKIM modules sign
> the MIME Content-* headers by default. Do you remember what opendkim
> does? A quick look at the code wasn't too enlightening.

Unfortunately, the most recently released version of opendkim doesn't sign 
any MIME headers by default.  Lacks RFC 8058's List-Unsubscribe-Post too.


Philip Guenther

___
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 Murray S. Kucherawy   said:
>I've read the middle part a few times and I don't understand either the
>attack or the proposed mitigation, so I think some examples might help.

The attack requires l= and an unsigned Content-Type header.

If Content-Type isn't signed, the bad guy can change the part boundary
string and then add new parts with the new boundary at the end. The
entire original message, which is all that the l= covers, is ignored
as junk before the first boundary.

I guess this isn't as obvious as the authors of 6376 thought since we still
have at least one person on this list insisting that you don't need to sign C-T.

On the other hand, I see that the perl and python DKIM modules sign
the MIME Content-* headers by default. Do you remember what opendkim
does? A quick look at the code wasn't too enlightening.

Requiring that the l= cover some minimum percentage of the message is
helpful but not that helpful, since you could add a short part with a
phish URL to a long message and probably still pass the percent rule.

On the third hand, I'm looking at mail in the IETF archives from
Verisign which has had DKIM signatures the l= tag since shortly after
the time they switched from Google to Ironport in late 2016. The set
of headers it signs is inconsistent. It always includes MIME-Version,
sometimes Content-Transfer-Encoding, and never Content-Type. So we do
have at least some examples where this bug exists.

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

[Alessandro Vesely]

On Thu 23/May/2024 16:44:07 +0200 Wei Chuang wrote:

On Mon, May 20, 2024 at 7:17 PM Murray S. Kucherawy  wrote:

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


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


Just specifically in regards authenticating mailing list modifications: 
fair enough that the ideas should be implemented first before any sort of 
IETF publication for it.  Still there ought to be a place for informal, 
early discussion of ideas on authenticating mailing lists.  For this 
proposal, I think there are issues around the intersection of DKIM signing 
and Content-type, and in particular, there will be advice such as in the 
researcher's blogpost 
 that 
calls for "h=" oversigning the Content-type header to help prevent the 
delimitter modification as was done.  While understandable, I suspect this 
prevents adding a mailing list footer as a new MIME part and perhaps too 
restrictive.  Instead would it be reasonable to say there be sufficient 
protection if the forwarder takes ownership of appended footers?  If not, 
another approach would be to version the Content-type header?  Yet another 
approach would be to resign the DKIM signature by the forwarder, but that 
hides who the sender is causing UI and spam filtering problems.



I agree that signing Content-Type: is overkill.


Going back to my original point, would the ietf-dkim list be the right place 
for this cross-cutting discussion?  I think there are a few targeted 
questions that need some discussion.  (We're interested prototyping but 
that's at least a quarter or so away)


I think mailmaint can be a good venue for airing these kind of proposals, 
without committing the WG to an extensive discussion, that is without I-D 
adoption.  Or is it better ietf-dkim?  Or ietf-smtp?



Best
Ale
--








___
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 Thu, May 23, 2024 at 7:44 AM Wei Chuang  wrote:

> Just specifically in regards authenticating mailing list modifications:
> fair enough that the ideas should be implemented first before any sort of
> IETF publication for it.  Still there ought to be a place for informal,
> early discussion of ideas on authenticating mailing lists.  For this
> proposal, I think there are issues around the intersection of DKIM signing
> and Content-type, and in particular, there will be advice such as in the
> researcher's blogpost
>  that
> calls for "h=" oversigning the Content-type header to help prevent the
> delimitter modification as was done.  While understandable, I suspect this
> prevents adding a mailing list footer as a new MIME part and perhaps too
> restrictive.  Instead would it be reasonable to say there be sufficient
> protection if the forwarder takes ownership of appended footers?  If not,
> another approach would be to version the Content-type header?  Yet another
> approach would be to resign the DKIM signature by the forwarder, but that
> hides who the sender is causing UI and spam filtering problems.  Going back
> to my original point, would the ietf-dkim list be the right place for this
> cross-cutting discussion?  I think there are a few targeted questions that
> need some discussion.  (We're interested prototyping but that's at least a
> quarter or so away)
>

I think this is a fine place to have the discussion.  Or at least I can't
think of a better one.

I've read the middle part a few times and I don't understand either the
attack or the proposed mitigation, so I think some examples might help.
Taking a multipart message that signs (but does not oversign) Content-Type
in order to add a footer or something would still invalidate the message
because the body would be different, even near the top (within any "l="
that is not zero).  That's also true for adding Content-Type that wasn't
there; the top of the message would need to change.

-MSK
___
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 7:17 PM Murray S. Kucherawy 
wrote:

> On Sun, May 19, 2024 at 9:27 AM Wei Chuang  40google@dmarc.ietf.org> wrote:
>


>
>
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.
>
>
Just specifically in regards authenticating mailing list modifications:
fair enough that the ideas should be implemented first before any sort of
IETF publication for it.  Still there ought to be a place for informal,
early discussion of ideas on authenticating mailing lists.  For this
proposal, I think there are issues around the intersection of DKIM signing
and Content-type, and in particular, there will be advice such as in the
researcher's blogpost
 that
calls for "h=" oversigning the Content-type header to help prevent the
delimitter modification as was done.  While understandable, I suspect this
prevents adding a mailing list footer as a new MIME part and perhaps too
restrictive.  Instead would it be reasonable to say there be sufficient
protection if the forwarder takes ownership of appended footers?  If not,
another approach would be to version the Content-type header?  Yet another
approach would be to resign the DKIM signature by the forwarder, but that
hides who the sender is causing UI and spam filtering problems.  Going back
to my original point, would the ietf-dkim list be the right place for this
cross-cutting discussion?  I think there are a few targeted questions that
need some discussion.  (We're interested prototyping but that's at least a
quarter or so away)

-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

[Alessandro Vesely]

On Tue 21/May/2024 16:41:20 +0200 John Levine wrote:

It appears that Alessandro Vesely   said:

I'd be curious to learn why [John would certainly want the signature to 
break if someone changed the Content-Type header on a message he sent].  A 
mailing list might change it from >>

   Content-type: text/plain; charset=utf-8
to
   Content-Type: text/plain; charset="utf-8"


I have trouble imagining that many mailing lists would make that 
change and only that change and would otherwise leave the message 
untouched.



The other change they did, footer addition, can be easily undone.  Guessing 
whether the original C-T had quotes rather than us-ascii or what else would 
require several attempts, which makes it not worth.



In any event, as we've now said several times, the Content-Type attack 
is specifically described in RFC 6376.  I see that the perl and python 
DKIM modules sign the content-* headers by default.



That attack only works if there is l=, AFAIK.

I've seen several blogs recommending to sign "technical" fields like 
Content-Type, Content-Transfer-Encoding and even MIME-Version.  I really don't 
think this message would take on a different meaning if someone changed that to 
be, say, MIME-Version: 1.5.



Best
Ale
--



___
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=". 

It looks like the l= senders are largely one ESP who said today they
have stopped doing it, and companies that use poorly configured
Ironport appliances.

Since RFC 6376 already says not to do what this "disclosure" describes,
I think it's more likely to be effective to follow up with the people
who are using l= and encourage them to fix it.  So far nobody has
pushed back when told of the issue.

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

[John Levine]

It appears that Alessandro Vesely   said:
>On Mon 20/May/2024 20:10:44 +0200 John Levine wrote:
>> 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.
>
>Informally, I think it's quite straightforward to distinguish between 
>technical 
>versus semantic fields.

I still have no idea what headers you'd consider to be technical.  Message-ID?  
Expires?
(Don't tell me, it's not helpful.)

>I'd be curious to learn why.  A mailing list might change it from
>
>Content-type: text/plain; charset=utf-8
>to
>Content-Type: text/plain; charset="utf-8"

I have trouble imagining that many mailing lists would make that
change and only that change and would otherwise leave the messasge
untouched.

In any event, as we've now said several times, the Content-Type attack
is specifically described in RFC 6376.  I see that the perl and python
DKIM modules sign the content-* headers by default.

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

[Alessandro Vesely]

On Mon 20/May/2024 20:10:44 +0200 John Levine wrote:

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.



Informally, I think it's quite straightforward to distinguish between technical 
versus semantic fields.



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.



I'd be curious to learn why.  A mailing list might change it from

   Content-type: text/plain; charset=utf-8

to

   Content-Type: text/plain; charset="utf-8"

which makes the signature unrecoverable, as in the case of the message I'm 
replying to.  Or they may want to wrap the message into a multipart with a 
footer.  For consistency, they set that field to the correct value which 
describes the structure of the message they distribute.  Why would that change 
matter when the semantic part of the message is unaltered?



Best
Ale
--




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

[Ietf-dkim] Re: DKIM with body length

[Jeremy Harris]

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

[John Levine]

It appears that Dave Crocker   said:
>What I  am suggesting is /first/ getting a substantial base of industry 
>agreement, through collective action and field practice, and /then/ 
>codifying it with an update specification.
>
>The specification through the IETF would then merely document a new 
>established practice.
>
>Do not start with an IETF process.  End with it.

Considering how few senders use l= I would start by trying to contact some
of them and see if they realize what they're doing.

Anyone know who runs Verisign's mail system?

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

[John Levine]

It appears that Steve Atkins   said:
>> Do people really think that senders that are ignoring Sec. 8.2 of RFC 6376 
>> are going to pay attention to a separate RFC
>that updates that RFC?
>
>+1. Senders, no.

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.

>But there are already major mail receivers who treat any DKIM signature 
>containing l= to be invalid.

That will definitely get their attention.

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

[Dave Crocker]

On 5/19/2024 9:26 AM, Wei Chuang wrote:
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. 


What I  am suggesting is /first/ getting a substantial base of industry 
agreement, through collective action and field practice, and /then/ 
codifying it with an update specification.


The specification through the IETF would then merely document a new 
established practice.


Do not start with an IETF process.  End with it.

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

[Steve Atkins]

> On 19 May 2024, at 17:32, Jim Fenton  wrote:
> 
> [adding the mailmaint mailing list]
> 
> 
> On 19 May 2024, at 9:26, Wei Chuang wrote:
> 
>> Hi DKIM folks,
>> As many of you know there was a DKIM security vulnerability disclosure
>> Friday around the signature header body length tag "l=". 
> 
> Do people really think that senders that are ignoring Sec. 8.2 of RFC 6376 
> are going to pay attention to a separate RFC that updates that RFC?

+1. Senders, no.

But there are already major mail receivers who treat any DKIM signature 
containing l= to be invalid.

Cheers,
  Steve
___
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

[Jim Fenton]

[adding the mailmaint mailing list]


On 19 May 2024, at 9:26, Wei Chuang wrote:

> 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 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.
>
> Others have noted that the amount of traffic using DKIM w/body length is
> small, and from where I sit in Gmail I would agree.  However I also agree
> with the blog post authors based on that same data that many of the
> impacted domains are systemically important email senders that really
> should be paying attention to the RFC section 8.2 and their email security
> much more carefully.  Some of the names are mentioned in the blog post and
> that should be sufficient to convince everyone of the risk.  I would argue
> that the body length feature in DKIM represents a significant spoofing
> hence security risk and that it must be discouraged to the extent
> possible.  The standards community can help by deprecating the body length
> tag "l=" from the DKIM RFC.
>
> 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.

Do people really think that senders that are ignoring Sec. 8.2 of RFC 6376 are 
going to pay attention to a separate RFC that updates that RFC?

-Jim

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