Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
On Mon, Jul 6, 2020 at 10:12 AM Dave Crocker wrote: > Perhaps, like some others, I'm not understanding this correctly, but I > think the proposal has nothing at all to do with what the recipient sees. > Rather, I've understood this as an attempt to reverse additions made by a > Mediator, with the goal of validating the origination DKIM signature. > Presumably that is so as to use the origination domain's reputation and > even permit DMARC to validate. > Right, primarily. It occurs to me that if you can recover the original content and thus validate the author domain signature, you could opt to deliver that version of the content to the user, permanently reversing the transformations. But that's mainly a reply to John's point that a spammer could drop a blob of junk onto a legitimate message; the verifier could simply reverse it. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Integrated scanrios (was: Re: Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt)
On Mon, Jul 6, 2020 at 11:18 AM John Levine wrote: > In article you write: > > > >It occurs to me that discussion about how this latest proposal might or > >might not have similarities to ARC should encourage everyone making a > >proposal to add commentary that gives a full sense of end-to-end use. > > Agreed. Hence my point that this is much harder to integrate into > mailing lists, and the useful signal you get, that you started with a > valid message from some X, is the same. > There's a distinction though. ARC tells you "that guy over there said the original message passed", and you have to trust it. On the other hand, the transformations draft, when it works, hands you the original message, and you don't have to make that trust assessment. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
In article <3129f12e02434273915ed6f91a998...@bayviewphysicians.com> you write: >About credible mediators: >You are right that if an inbound email gateway believes a Mediator is >credible, then all that is necessary is for >the Mediator to prove his own identity.But what is the mechanism by which >a Mediator obtains the trust of the >email gateway? And by what mechanism does the Mediator know that the email >gateway has determined it to be >credible? Please see previous discussions about the design of ARC. There's reasons it's not just a whitelist of mailing lists. -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
In article <0dd5f575c0e944da832b73a713abb...@bayviewphysicians.com> you write: >-=-=-=-=-=- > >This surprises me: > >This proposal makes lists sort through all of the changes they make >and try to figure out which ones match a tag and which ones don't. >That is surprisingly hard, e.g., I found that when you have >multipart/alternative and add a message header, it edits the header >text into both of the alternative versions. Good luck unscrambling that. > >I expected that the tag would be a function of the algorithm used by the MLM >or forwarder, rather than the >particulars of each message. You would be mistaken. List management software has a vast array of options for message handling. The changes to each message depend on both how the particular list is configured and what's in the message. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
About discarding From alignment: DMARC has been sold to big corporations as essential to defending their brand identity.In response, they pay serious money to keep Valimail and its competitors in business. I see no way that we can put forward a proposal that will put Valimail and its friends out of business, while incurring the wrath of C-Level executives and legal teams at Fortune 500 companies. Not that I have any of those people on speed dial, so maybe someone can prove me wrong. But I have been surprised that one of the DMARC reporting companies is not listening to this part of the discussion and having alarm bells. About credible mediators: You are right that if an inbound email gateway believes a Mediator is credible, then all that is necessary is for the Mediator to prove his own identity. But what is the mechanism by which a Mediator obtains the trust of the email gateway? And by what mechanism does the Mediator know that the email gateway has determined it to be credible? One option is to provide so much information in the email message that the email gateway will grant trust on the fly.Murray's approach has appeal because, especially when coupled with appropriate LIST-* and RESENT-* headers, it provides all of the information needed for a decision to be made. ARC has less appeal because it provides just enough information for the email gateway to detect that something deliberate was done, but not much more. Researching the credibility of the list would need to occur out-of-band using LIST-* headers as a starting point. But there is a larger problem. Even after the gateway decides the Mediator is credible, the Mediator is ignorant of the gateway's decision, so the Mediator is unable to take advantage of that decision. The other option is for the MLM and the Email gateway administration to negotiate credibility in advance, with the subscriber acting as sponsor for the discussion. DF From: Jim Fenton Sent: 7/6/20 2:33 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt On 7/6/20 10:41 AM, John R Levine wrote: > On Mon, 6 Jul 2020, Dave Crocker wrote: >>> I don't understand this scenario at all. Why would I want to show >>> my user a message forwarded by a spammer? If the original sender >>> wanted me to see it, she could have sent it to me directly, or >>> through a legit mailing list. >> >> Perhaps, like some others, I'm not understanding this correctly, but >> I think the proposal has nothing at all to do with what the recipient >> sees. Rather, I've understood this as an attempt to reverse >> additions made by a Mediator, with the goal of validating the >> origination DKIM signature. Presumably that is so as to use the >> origination domain's reputation and even permit DMARC to validate. > > But why would I want to do that? ARC lets a credible mediator say > this message was OK before I munged it. This proposal lets a sleazy > mediator say the same thing, with advice on how to verify mechanically. Your use of "credible mediator" and "sleazy mediator" emphasizes that we're depending on the mediator behaving responsibly. Given that's the case, why not just expect a responsible mediator to verify the DKIM signature (or maybe SPF) on the incoming message, check its alignment with the From: domain, then make whatever modifications it wants to make, then re-sign the message with the mediator's DKIM signature containing a tag that says it did all of the above? Yes, this is a "get out of DMARC free" card for mediators to use. But we're already dependent on being able to distinguish between credible mediators and sleazy mediators, and this tag simply says, "if you trust that I'm a credible mediator and this message has a valid signature from me, you should accept the message even if my signature doesn't align with the From: domain." This gets us out of the business of trying to define what acceptable and unacceptable transformations are. If the transformation was done by a credible mediator, it's acceptable. Many (most?) mediators do not currently require authentication (+alignment) on incoming messages. They could continue to forward the unauthenticated messages, but without the new tag. -Jim P.S. I'm still not sold on the value of From: domain alignment, but left that in here to avoid conflating too many different ideas. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
This surprises me: This proposal makes lists sort through all of the changes they make and try to figure out which ones match a tag and which ones don't. That is surprisingly hard, e.g., I found that when you have multipart/alternative and add a message header, it edits the header text into both of the alternative versions. Good luck unscrambling that. I expected that the tag would be a function of the algorithm used by the MLM or forwarder, rather than the particulars of each message. In a face-to-face conversation between MLM and recipient email administrator, the algorithm would be the topic of conversation, and would be the determinant of whether trust was established or not. At the same time, you raise an important point: The tag will be most useful if it will be reliably correct, but less useful if it is prone to errors.. In practice, the tag is likely to be fraught with human errors which introduce another layer of trust confusion: What do I do when the tag and the reversable content of the document are inconsistent with each other? We have a lot of those problems already. DF ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
On 7/6/20 3:41 PM, John Levine wrote: > In article , > Jim Fenton wrote: >> Your use of "credible mediator" and "sleazy mediator" emphasizes that >> we're depending on the mediator behaving responsibly. Given that's the >> case, why not just expect a responsible mediator to verify the DKIM >> signature (or maybe SPF) on the incoming message, check its alignment >> with the From: domain, then make whatever modifications it wants to >> make, then re-sign the message with the mediator's DKIM signature >> containing a tag that says it did all of the above? > According to people I've talked to about ARC, because mailing lists > don't do that. One of the things that makes it plausible that lists > might implement ARC is that it doesn't ask for any changes in the > internal operation of the list, just slap an ARC signature on the end. "Just slap an ARC signature on the end" greatly understates the complexity of ARC. > > It's also useful for other kinds of forwarding that don't change > anything but since they're forwards, SPF fails. If a mediator can add an ARC signature, they can add a DKIM signature. All this would add to DKIM signing is an additional tag indicating whether the message received by the mediator had an aligned signature or SPF. > > This proposal makes lists sort through all of the changes they make > and try to figure out which ones match a tag and which ones don't. > That is surprisingly hard, e.g., I found that when you have > multipart/alternative and add a message header, it edits the header > text into both of the alternative versions. Good luck unscrambling that. Perhaps I didn't explain this clearly enough. Mediators don't need to sort through changes at all. All they do is check to see if the incoming message had an aligned signature or SPF, and include a tag in the DKIM signature that they apply indicating that. Receiving domains that intend to enforce DMARC would need to verify the DKIM signature of the mediator, and if the signature came from a credible mediator and the tag is present, accept the message as though it had an aligned signature. -Jim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
In article , Jim Fenton wrote: >Your use of "credible mediator" and "sleazy mediator" emphasizes that >we're depending on the mediator behaving responsibly. Given that's the >case, why not just expect a responsible mediator to verify the DKIM >signature (or maybe SPF) on the incoming message, check its alignment >with the From: domain, then make whatever modifications it wants to >make, then re-sign the message with the mediator's DKIM signature >containing a tag that says it did all of the above? According to people I've talked to about ARC, because mailing lists don't do that. One of the things that makes it plausible that lists might implement ARC is that it doesn't ask for any changes in the internal operation of the list, just slap an ARC signature on the end. It's also useful for other kinds of forwarding that don't change anything but since they're forwards, SPF fails. This proposal makes lists sort through all of the changes they make and try to figure out which ones match a tag and which ones don't. That is surprisingly hard, e.g., I found that when you have multipart/alternative and add a message header, it edits the header text into both of the alternative versions. Good luck unscrambling that. -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
On 7/6/20 10:41 AM, John R Levine wrote: > On Mon, 6 Jul 2020, Dave Crocker wrote: >>> I don't understand this scenario at all. Why would I want to show >>> my user a message forwarded by a spammer? If the original sender >>> wanted me to see it, she could have sent it to me directly, or >>> through a legit mailing list. >> >> Perhaps, like some others, I'm not understanding this correctly, but >> I think the proposal has nothing at all to do with what the recipient >> sees. Rather, I've understood this as an attempt to reverse >> additions made by a Mediator, with the goal of validating the >> origination DKIM signature. Presumably that is so as to use the >> origination domain's reputation and even permit DMARC to validate. > > But why would I want to do that? ARC lets a credible mediator say > this message was OK before I munged it. This proposal lets a sleazy > mediator say the same thing, with advice on how to verify mechanically. Your use of "credible mediator" and "sleazy mediator" emphasizes that we're depending on the mediator behaving responsibly. Given that's the case, why not just expect a responsible mediator to verify the DKIM signature (or maybe SPF) on the incoming message, check its alignment with the From: domain, then make whatever modifications it wants to make, then re-sign the message with the mediator's DKIM signature containing a tag that says it did all of the above? Yes, this is a "get out of DMARC free" card for mediators to use. But we're already dependent on being able to distinguish between credible mediators and sleazy mediators, and this tag simply says, "if you trust that I'm a credible mediator and this message has a valid signature from me, you should accept the message even if my signature doesn't align with the From: domain." This gets us out of the business of trying to define what acceptable and unacceptable transformations are. If the transformation was done by a credible mediator, it's acceptable. Many (most?) mediators do not currently require authentication (+alignment) on incoming messages. They could continue to forward the unauthenticated messages, but without the new tag. -Jim P.S. I'm still not sold on the value of From: domain alignment, but left that in here to avoid conflating too many different ideas. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
On Mon 06/Jul/2020 19:17:42 +0200 ned+dmarc wrote: On Mon 06/Jul/2020 11:24:19 +0200 Murray S. Kucherawy wrote: On Mon, Jul 6, 2020 at 1:49 AM Alessandro Vesely wrote: For multipart messages, transformations may need to replace boundaries. In that case, the "restricted patch" to undo the transformation may require more data than it is convenient to store in a DKIM tag. >> Replace why? It might need to add its own, but it's easy to undo that. Oops, I thought MLM generated boundaries anew. It seems that's not the case. Depends on the MLM and what it is doing. For example, boundary marker regeneration can happen if you're adding a header or a footer to a multipart message. So that kind is going to go among forbidden transformations. Still, the original Content-Type is difficult to reproduce exactly. You need to know whether the boundary= parameter is written as a token or a quoted-string, and, if not c=relaxed, spaces and newlines. If longer than a few bits, the info to undo the transformation (a reverse patch?) could be stored in its own field, or even in an attachment. Another difficulty, IIRC, is reordering of To:. This can simply be avoided. In order to be useful, this only needs to do what MLMs commonly do already. We don't need to cover the universe of possible futures right away. Agreed. MLMs code has no lack of conditionals. Probably this technique can address a class of mailing lists somewhat wider than the "no-changes" class, without trying to cover even one half of /present/ MLM possibilities. Shall say just enough to cover IETF mailing lists? The problem is that list software wasn't designed with the idea of keeping changes to an invertible/removable minimum in mind. So you're going to see many/most of the transformations this document deals with done in ways other than what the document describes. So in order to make use of this document you're basically talking about a fairly major rewrite. Yet, setting no-changes does guarantee no breakage occurs. Hm... does it? I didn't carry out thorough tests. Looking at my own messages to this list, which are signed with l=, I see my DKIM signatures are broken intermittently. It would be enough to turn off base64 encoding. It is no major rewrite... I think that's unlikely to happen. Which is probably why this draft was let expire. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Integrated scanrios (was: Re: Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt)
In article you write: > >It occurs to me that discussion about how this latest proposal might or >might not have similarities to ARC should encourage everyone making a >proposal to add commentary that gives a full sense of end-to-end use. Agreed. Hence my point that this is much harder to integrate into mailing lists, and the useful signal you get, that you started with a valid message from some X, is the same. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Integrated scanrios (was: Re: Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt)
It occurs to me that discussion about how this latest proposal might or might not have similarities to ARC should encourage everyone making a proposal to add commentary that gives a full sense of end-to-end use. That is, distinguish the details of how the specific mechanism works, from how it integrates into end-to-end service. How is it expected to get used and why is that believed to be practical (as well as useful?) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
On 7/6/2020 10:41 AM, John R Levine wrote: On Mon, 6 Jul 2020, Dave Crocker wrote: Perhaps, like some others, I'm not understanding this correctly, but I think the proposal has nothing at all to do with what the recipient sees. Rather, I've understood this as an attempt to reverse additions made by a Mediator, with the goal of validating the origination DKIM signature. Presumably that is so as to use the origination domain's reputation and even permit DMARC to validate. But why would I want to do that? I wasn't advocating or criticizing. Just trying to synchronize that nature and purpose of the task. ARC lets a credible mediator say this message was OK before I munged it. That's a very different trust model from allowing a means to directly vet the original signature. This proposal lets a sleazy mediator say the same thing, with advice on how to verify mechanically. Actually, it doesn't. The sleazy mediator cannot somehow forge an originator's signature so it validates. A sleazy mediator takes a message from Paypal and wraps a big blob of HTML spam around it that will display on top of the original message. I get the spammy message, look at the signatures and find yup, there's a real Paypal message inside the spam. What should I do with it? It's unlikely the Paypal message was intended for me. A worthy scenario to worry about, but completely different from the nature of what ARC does and its likely benefits and weaknesses. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
On Mon, 6 Jul 2020, Dave Crocker wrote: I don't understand this scenario at all. Why would I want to show my user a message forwarded by a spammer? If the original sender wanted me to see it, she could have sent it to me directly, or through a legit mailing list. Perhaps, like some others, I'm not understanding this correctly, but I think the proposal has nothing at all to do with what the recipient sees. Rather, I've understood this as an attempt to reverse additions made by a Mediator, with the goal of validating the origination DKIM signature. Presumably that is so as to use the origination domain's reputation and even permit DMARC to validate. But why would I want to do that? ARC lets a credible mediator say this message was OK before I munged it. This proposal lets a sleazy mediator say the same thing, with advice on how to verify mechanically. A sleazy mediator takes a message from Paypal and wraps a big blob of HTML spam around it that will display on top of the original message. I get the spammy message, look at the signatures and find yup, there's a real Paypal message inside the spam. What should I do with it? It's unlikely the Paypal message was intended for me. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
On Mon 06/Jul/2020 11:24:19 +0200 Murray S. Kucherawy wrote: > On Mon, Jul 6, 2020 at 1:49 AM Alessandro Vesely wrote: > >> For multipart messages, transformations may need to replace boundaries. >> In that case, the "restricted patch" to undo the transformation may >> require more data than it is convenient to store in a DKIM tag. >> > > Replace why? It might need to add its own, but it's easy to undo that. Oops, I thought MLM generated boundaries anew. It seems that's not the case. Depends on the MLM and what it is doing. For example, boundary marker regeneration can happen if you're adding a header or a footer to a multipart message. Still, the original Content-Type is difficult to reproduce exactly. You need to know whether the boundary= parameter is written as a token or a quoted-string, and, if not c=relaxed, spaces and newlines. If longer than a few bits, the info to undo the transformation (a reverse patch?) could be stored in its own field, or even in an attachment. Another difficulty, IIRC, is reordering of To:. This can simply be avoided. > In order to be useful, this only needs to do what MLMs commonly do > already. We don't need to cover the universe of possible futures right > away. Agreed. MLMs code has no lack of conditionals. Probably this technique can address a class of mailing lists somewhat wider than the "no-changes" class, without trying to cover even one half of /present/ MLM possibilities. Shall say just enough to cover IETF mailing lists? The problem is that list software wasn't designed with the idea of keeping changes to an invertible/removable minimum in mind. So you're going to see many/most of the transformations this document deals with done in ways other than what the document describes. So in order to make use of this document you're basically talking about a fairly major rewrite. I think that's unlikely to happen. Ned ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
On Mon 06/Jul/2020 18:49:11 +0200 Murray S. Kucherawy wrote: On Mon, Jul 6, 2020 at 8:43 AM Doug Foster wrote: ·The email administration then reviews the request and replies to user and MLM in one of three ways: This needs to be automatable, or it won't scale to very large operations. I suspect there's virtually zero chance a GMail sized operation will staff up to review requests given the size of their customer base. It can be automated by having logged-in users interact with a suitable server-side program. That approach can work for (small) mailbox providers which trust their users. That set seems to be close to the complement of the ones who can use ARC, doesn't it? And once it's automated, there needs to be a strategy for dealing with stale data (e.g., old lists nobody is using anymore), etc. Yes, it would be an improvement of the current subscription reminders —a time distributed database. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
On 7/6/2020 10:03 AM, John R Levine wrote: No, I'm not saying render them differently. I'm saying that if the second signature passes, then the second one signed the bolted-on spam but also told you how to strip it away to get the original. So, do that; if the author signature now passes, you have the original "clean" message to show instead of the hijacked message. If not, you have a spammy message to deal with, as before. I don't understand this scenario at all. Why would I want to show my user a message forwarded by a spammer? If the original sender wanted me to see it, she could have sent it to me directly, or through a legit mailing list. Perhaps, like some others, I'm not understanding this correctly, but I think the proposal has nothing at all to do with what the recipient sees. Rather, I've understood this as an attempt to reverse additions made by a Mediator, with the goal of validating the origination DKIM signature. Presumably that is so as to use the origination domain's reputation and even permit DMARC to validate. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
On Mon 06/Jul/2020 11:24:19 +0200 Murray S. Kucherawy wrote: On Mon, Jul 6, 2020 at 1:49 AM Alessandro Vesely wrote: For multipart messages, transformations may need to replace boundaries. In that case, the "restricted patch" to undo the transformation may require more data than it is convenient to store in a DKIM tag. >> Replace why? It might need to add its own, but it's easy to undo that. Oops, I thought MLM generated boundaries anew. It seems that's not the case. Still, the original Content-Type is difficult to reproduce exactly. You need to know whether the boundary= parameter is written as a token or a quoted-string, and, if not c=relaxed, spaces and newlines. If longer than a few bits, the info to undo the transformation (a reverse patch?) could be stored in its own field, or even in an attachment. Another difficulty, IIRC, is reordering of To:. This can simply be avoided. In order to be useful, this only needs to do what MLMs commonly do already. We don't need to cover the universe of possible futures right away. Agreed. MLMs code has no lack of conditionals. Probably this technique can address a class of mailing lists somewhat wider than the "no-changes" class, without trying to cover even one half of /present/ MLM possibilities. Shall say just enough to cover IETF mailing lists? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
On Mon, 6 Jul 2020, Murray S. Kucherawy wrote: No, I'm not saying render them differently. I'm saying that if the second signature passes, then the second one signed the bolted-on spam but also told you how to strip it away to get the original. So, do that; if the author signature now passes, you have the original "clean" message to show instead of the hijacked message. If not, you have a spammy message to deal with, as before. I don't understand this scenario at all. Why would I want to show my user a message forwarded by a spammer? If the original sender wanted me to see it, she could have sent it to me directly, or through a legit mailing list. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
On Mon, Jul 6, 2020 at 8:43 AM Doug Foster wrote: > · Mailing list M sends a message to User A with a request to > ensure that the inbound gateway will accepts its message. The message > contains attachments needed to define and justify the request.I > envision an XML attachment for use with automation, and a text file for > non-automated environments. An XLST file could be used to convert the XML > to TXT, to validate that the XML attachment and the text attachment are > really stating the same thing. > The first thing that comes to mind for things like this is whether and how spammers will try to use this to clear a path to the inbox. How do you know this XML blob is coming from a bona fide list? Anecdotally, spammers were the first to adopt DKIM. This wouldn't be any different. · The email administration then reviews the request and replies to > user and MLM in one of three ways: > This needs to be automatable, or it won't scale to very large operations. I suspect there's virtually zero chance a GMail sized operation will staff up to review requests given the size of their customer base. And once it's automated, there needs to be a strategy for dealing with stale data (e.g., old lists nobody is using anymore), etc. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
On Mon, Jul 6, 2020 at 7:31 AM John R Levine wrote: > > That isn't a new attack though, given spammers sign their email already. > > This way you have (in theory) two good signatures: one from the author > for > > the "safe" form of the message, and one for the spam that got bolted on, > > and you could in theory strip the spam before you deliver because you > know > > exactly what it is. > > But then what? Surely we're not going to revisit the WKBI of showing > different parts of the message in different colors depending on whether > they're signed. If it's got bolted on spam, you treat the message as spam > so I don't see that this has gained you anything. > No, I'm not saying render them differently. I'm saying that if the second signature passes, then the second one signed the bolted-on spam but also told you how to strip it away to get the original. So, do that; if the author signature now passes, you have the original "clean" message to show instead of the hijacked message. If not, you have a spammy message to deal with, as before. If the second signature doesn't pass in the first place, then it's ignored, and you still have spam to deal with. Of course, the original message might be spam too, but that's not new either. This isn't meant to solve spam. It's meant to deal with the legitimate MLM+DKIM+DMARC case. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
If MLM changes are not reversible, we still have the problem of convincing the recipient gateway to trust the modified message. At first glance, this is an internal issue between the user who created the subscription and his email security administrator, and that communication is not obviously an IETF problem.But in a large consumer-focused environment like Gmail, or even within a Fortune 500 enterprise, some level of automation may be necessary. Additionally, the email filter MTA and the mail store are often separate products from separate companies, so we have an multi-vendor interoperability issue. Collectively this seems to make an IETF specification appropriate. At present, email gateways have very limited ability to distinguish between solicited and unsolicited mail. Some implementations check for a match on the user’s contact list. Other products check for outbound messages to the sender.Giving the email gateway better information about subscribed mail flows should improve filtering accuracy. This is the scenario in my head, a variant of something posted previously: · User A subscribes to mailing list M. · Mailing list M sends a message to User A with a request to ensure that the inbound gateway will accepts its message. The message contains attachments needed to define and justify the request.I envision an XML attachment for use with automation, and a text file for non-automated environments. An XLST file could be used to convert the XML to TXT, to validate that the XML attachment and the text attachment are really stating the same thing. · The configuration files provide this type of information: o The header fields which will uniquely identify message from this subscription, and the tests which can be performed to validate those headers. o The administrative contacts for the list. o Whether the list makes DKIM-invalidating changes, and why. o For Murray’s approach: Whether the changes will be fully or partially reversible and whether it supports the tf extension. o For John’s approach: Whether or not the list implements ARC. · The email administration then reviews the request and replies to user and MLM in one of three ways: o Fully Approved - any required gateway trust changes have been implemented. For automated systems, the XML file is used to apply these changes. o Strongly rejected - subscription is contrary to policy and should be cancelled; user should assume that any incoming messages will be blocked. o Neutral – Subscription is not rejected but no trust changes will be made. Any particular message may or may not be blocked. Would this be more likely to succeed than the alternatives? DF ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
I wrote the Sympa ARC code which is entwined with the DKIM code so that would probably be me. Honestly, this looks like a lot more work than ARC to get a result likely to be worse in practice than ARC. Interesting; I had the opposite experience, and I had a lot of our DKIM code to recycle when I built our ARC implementation. This idea doesn't seem nearly as complicated to implement. Moreover, ARC is a much more heavyweight addition to the stack than a new DKIM tag would be. I was thinking of the work involved in putting it into the mailing list software. ARC was straightforward, one bit where the messages come in to recard the A-R header, another bit cloned from the DKIM code to apply the seal. For this I'd need to go through vast amounts of code looking for every place that changes the message and figuring out what change might map onto what DKIM key, and we still have a lot of changes that don't map onto anything, so now some changes are safer than others. It would not be hard for a bad guy to use the footer or add-part transformation to lay a big spammy blob ... That isn't a new attack though, given spammers sign their email already. This way you have (in theory) two good signatures: one from the author for the "safe" form of the message, and one for the spam that got bolted on, and you could in theory strip the spam before you deliver because you know exactly what it is. But then what? Surely we're not going to revisit the WKBI of showing different parts of the message in different colors depending on whether they're signed. If it's got bolted on spam, you treat the message as spam so I don't see that this has gained you anything. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
Doug Foster skrev den 2020-07-06 14:48: I like the idea of making signatures recoverable wherever possible. For mailing lists, I wonder if this approach is sufficient to solve the whole problem. If the MLM transformation is for security rather than informational purposes, I expect that the transformations will be (even should be) non-reversible. For some spam filters, it might be important. Lots of spam filters add DKIM-invalidating content upon entry to the protected domain. Many of those changes should be reversible. URL rewrite is the most difficult to reverse using this approach. However, when the incoming and outgoing email gateways are from the same vendor, as I suspect is often the case, the reversal should already be feasible using proprietary methods. Is any known spam filter vendor doing this type of reversal? i know mailman can do the right things, ARC sealing, and then nothing more, then its op to DMARC to test results from ARC, job done but this does not work if DKIM is breaked before ARC sealing is done, and DMARC testing is not yet maked into stable releases yet, and in gentoo none of it exists i have dropped OpenDKIM, OpenARC, OpenDMARC, and now just live with fuglu modification and thereby confirm that the original signature still verifies against the original content. in the end it might work better if maillists in generic does not try to fix anything thay self creates as a problem to solve, dovecot and postfix maillists is known to not break DKIM, and currrently only dovecot is doing ARC sealing, not the worst case, but nice to know that maillist can stop breaking DKIM hope it will be standard in 2021 finaly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
I like the idea of making signatures recoverable wherever possible. For mailing lists, I wonder if this approach is sufficient to solve the whole problem. If the MLM transformation is for security rather than informational purposes, I expect that the transformations will be (even should be) non-reversible. For some spam filters, it might be important. Lots of spam filters add DKIM-invalidating content upon entry to the protected domain. Many of those changes should be reversible. URL rewrite is the most difficult to reverse using this approach. However, when the incoming and outgoing email gateways are from the same vendor, as I suspect is often the case, the reversal should already be feasible using proprietary methods. Is any known spam filter vendor doing this type of reversal? DF From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Sunday, July 05, 2020 5:56 PM To: IETF DMARC WG Subject: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt I decided to breathe life into this idea since it's relevant and got some discussion recently. Comments welcome. I'm talking to the Mailman people about the idea now; this is based on some things they mentioned. I haven't managed to get the attention of Sympa or L-Soft yet. -MSK -- Forwarded message - From: Date: Sun, Jul 5, 2020 at 2:46 PM Subject: New Version Notification for draft-kucherawy-dkim-transform-01.txt To: Murray S. Kucherawy A new version of I-D, draft-kucherawy-dkim-transform-01.txt has been successfully submitted by Murray Kucherawy and posted to the IETF repository. Name: draft-kucherawy-dkim-transform Revision: 01 Title: Recognized Transformations of Messages Bearing DomainKeys Identified Mail (DKIM) Signatures Document date: 2020-07-05 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-kucherawy-dkim-transform-01.txt Status: https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/ Htmlized: https://tools.ietf.org/html/draft-kucherawy-dkim-transform-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-transform Diff: https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-transform-01 Abstract: DomainKeys Identified Mail (DKIM) introduced a mechanism whereby a mail operator can affix a signature to a message that validates at the level of the signer's domain name. It specified two possible ways of converting the message body to a canonical form, one intolerant of changes and the other tolerant of simple changes to whitespace within the message body. The provided canonicalization schemes do not tolerate changes in a message such as conversion between transfer encodings or addition of new message content. It is useful to have these capabilities to allow for transport through gateways, and also for transport through handlers (such as mailing list services) that might add content that would invalidate a signature generated using the existing canonicalization schemes. This document presents a mechanism for declaring that a message underwent one of a handful of well-defined transformations prior to being re-signed by a mediator, so that a verifier might rewind such a modification and thereby confirm that the original signature still verifies against the original content. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
On Mon, Jul 6, 2020 at 1:49 AM Alessandro Vesely wrote: > For multipart messages, transformations may need to replace boundaries. > In > that case, the "restricted patch" to undo the transformation may require > more > data than it is convenient to store in a DKIM tag. > Replace why? It might need to add its own, but it's easy to undo that. In order to be useful, this only needs to do what MLMs commonly do already. We don't need to cover the universe of possible futures right away. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Base64 encoding (some?) IETF messages
On Mon 06/Jul/2020 10:49:06 +0200 Alessandro Vesely wrote: Rather than deprecate l=, perhaps we could just have noticed that it only makes sense in text/plain messages, where it allows the addition of a footer. For example, this message [...]now that IETF seems to have given up base64 encoding[...] should feature an unbroken author signature. It doesn't. It was base64 encoded. Perhaps because of non-ASCII characters (which I elided in the quotation above)? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-transform-01.txt
On Mon 06/Jul/2020 06:50:45 +0200 Jim Fenton wrote: On 7/5/20 7:42 PM, John Levine wrote: It would not be hard for a bad guy to use the footer or add-part transformation to lay a big spammy blob on top of some innocuous original message. Rather than play cat and mouse and try to figure one when a change is too big, recipients would use this the same way they use ARC, and only check it on mail from senders who are generally well behaved. That was basically the argument against the l= parameter in DKIM signatures. We did end up keeping l= because it only has effect if the signer uses it and the verifier accepts its use, although it was widely expected that it would not be used much. I suspect that's what happened. The rationale for deprecating l= was that HTML and CSS allow appended content to be displayed before or even above (overlapping) the original content. I don't recall an actual proof of concept, though. Perhaps, we could have thought better: 1. In most cases, text/html is relegated in its own MIME entity. Multipart messages don't support simple append, except for the "epilogue" area. 2. In any case, the etag is covered by the signature. Added text would trigger quirks mode, and suppress CSS. Rather than deprecate l=, perhaps we could just have noticed that it only makes sense in text/plain messages, where it allows the addition of a footer. For example, this message —now that IETF seems to have given up base64 encoding— should feature an unbroken author signature. For multipart messages, transformations may need to replace boundaries. In that case, the "restricted patch" to undo the transformation may require more data than it is convenient to store in a DKIM tag. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
