[Ietf-dkim] Re: Fwd: WG Action: Formed Mail Maintenance (mailmaint) / Commitment
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. 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
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
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
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
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
> 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
[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
[Ietf-dkim] DKIM with body length
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. -Wei ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
