Re: [Ietf-dkim] Misuse of antiforgery protocols
> On Nov 29, 2022, at 8:25 PM, Jim Fenton wrote: > > > On 29 Nov 2022, at 18:54, Neil Anuskiewicz wrote: > > Unless I’m misunderstanding you’re saying those with an enforcing DMARC > policy can’t successfully send to mailing lists. I’m doing it now so I don’t > think DMARC has to stay inert if mailing lists. That’s a bit of a > generalization. > > _dmarc.marmot-tech.com. 300 IN TXT "v=DMARC1; p=none; > rua=mailto:dm...@marmot-tech.com; ruf=mailto:f...@marmot-tech.com; fo=1" > No, you don’t have an enforcing DMARC policy. But if you did, you would still > be able to successfully send to this mailing list, because IETF mailing lists > rewrite the From addresses of messages from enforcing domains. > My domains are all just toys so I’m always playing around but now changed marmot-tech.com’s policy back to reject. It bit embarrassing that I said it was at reject when it was at none, though. Anyway, yes mailman can handle DMARC as well as could be expected. I wish that certain widely used distribution list software could do the same. It’s not clear why that wouldn’t be addressed well for any DL software. It’s a pain. Neil___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On 12/7/22 4:26 PM, Murray S. Kucherawy wrote: Fair enough. Does the charter need to say that a revision to best practices, relative to the replay problem, might be a possible output? It's within the realm of possibility that no protocol work comes out of this, but a "checkpoint" about current realities might be good to publish in that case. This is why I'm extremely skeptical anything useful will come of this. We're putting the burden on the receiver to solve a sender's problem. That is the recipe for failure because what is the receiver's motivation to fund somebody else's problem? DKIM at least has the right incentives which is that senders have motivation for better delivery and receivers get utility in their fights against spam, etc. Regardless of solution, any solution to this has neither of those properties. The actual solution is for the sender to not send spam. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On 12/7/2022 4:26 PM, Murray S. Kucherawy wrote: Fair enough. Does the charter need to say that a revision to best practices, relative to the replay problem, might be a possible output? It's within the realm of possibility that no protocol work comes out of this, but a "checkpoint" about current realities might be good to publish in that case. That's what is ironic about this thread: I don't think there has been any suggestion to change the details of DKIM tech, just a refinement of DKIM intention. And maybe rather slight modification to expected use. But given actual current use, I doubt even that. Frankly, the word transit was included to get an essential point, without otherwise trying to tweak the wg work. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On December 8, 2022 12:26:45 AM UTC, "Murray S. Kucherawy" wrote: >On Wed, Dec 7, 2022 at 2:06 PM Dave Crocker wrote: > >> As appealing as the AS concept is, I've never been clear how operationally >> useful they are. >> >> More to the current point, if the anti-replay work to be done benefits >> from a position on transit vs. non-transit, then including it directly in >> an anti-replay specification would be more helpful than in a separate AS. >> >Fair enough. Does the charter need to say that a revision to best >practices, relative to the replay problem, might be a possible output? >It's within the realm of possibility that no protocol work comes out of >this, but a "checkpoint" about current realities might be good to publish >in that case. Yes. It's not a given that protocol changes are the only non-failure outcomes. Scott K ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On Wed, Dec 7, 2022 at 2:06 PM Dave Crocker wrote: > As appealing as the AS concept is, I've never been clear how operationally > useful they are. > > More to the current point, if the anti-replay work to be done benefits > from a position on transit vs. non-transit, then including it directly in > an anti-replay specification would be more helpful than in a separate AS. > Fair enough. Does the charter need to say that a revision to best practices, relative to the replay problem, might be a possible output? It's within the realm of possibility that no protocol work comes out of this, but a "checkpoint" about current realities might be good to publish in that case. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On 12/7/2022 1:47 PM, Murray S. Kucherawy wrote: Yes, it's definitely true that the standard was written from the perspective of delivery-time evaluation, and then sending that result to MUAs rather than having MUAs actually do the evaluation. So although 4686 says that's a design goal, 6376 sure doesn't have that flavor. I don't see either RFC clearly "disagreeing" with the view that DKIM is for transit-related work. That's contrary to Murray's assessment. But again, the RFC doesn't make that limitation clear (enough, IMO), either. Right, I think that's what I'm driving at. And because of this, we can't take "transit-time" as a given. Possibly beating this poor horse beyond equinimity... It's not meant to be about 'given' but about current reality. Even with the reality that the signatures are used forensically, that was not a design goal and, based on thoughtful consideration as reflected in that article, it's not very good for it. This of course doesn't prevent anyone from using it that way, but neither does it mean that a new specification has to accept that use as... acceptable. It is absolutely within the purview of the reconstituted WG to "fix" this by clarifying using current operational realities and acquired experience. An applicability statement, for instance, would not be out of the question. As appealing as the AS concept is, I've never been clear how operationally useful they are. More to the current point, if the anti-replay work to be done benefits from a position on transit vs. non-transit, then including it directly in an anti-replay specification would be more helpful than in a separate AS. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On 12/7/22 1:47 PM, Murray S. Kucherawy wrote: Yes, it's definitely true that the standard was written from the perspective of delivery-time evaluation, and then sending that result to MUAs rather than having MUAs actually do the evaluation. So although 4686 says that's a design goal, 6376 sure doesn't have that flavor. That's certainly what we had in mind as to how to deploy it, there certainly was no reason to preclude MUA's or other validators to use the signature as well. It is absolutely within the purview of the reconstituted WG to "fix" this by clarifying using current operational realities and acquired experience. An applicability statement, for instance, would not be out of the question. Part of the problem is that use for forensics is essentially opaque. We really can't know with any certainty how often it is used because companies aren't in the habit of letting the world know about phishing attacks against them, for example. And therein lies the problem: the only difference between forensics of the phishing kind and the Her Emails kind is the intent of the investigation which is a very layer 8 difference. For all of the layers below, they are identical. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On Tue, Dec 6, 2022 at 4:20 PM Dave Crocker wrote: > DKIM was developed to facilitate delivery handling decisions. The > language in the RFC 4871 and RFC 6376 doesn't make this as explicit as I'd > wish, given the perspective I'm advocating, but it's got some implicating > language. References to validation by MTAs or MDAs obviously has to do > with transit or delivery, and not after. Reference to MUAs might imply > long-term term. Or not. Certainly there is no discussion about long-term > use of the signature. > Yes, it's definitely true that the standard was written from the perspective of delivery-time evaluation, and then sending that result to MUAs rather than having MUAs actually do the evaluation. So although 4686 says that's a design goal, 6376 sure doesn't have that flavor. I don't see either RFC clearly "disagreeing" with the view that DKIM is for > transit-related work. That's contrary to Murray's assessment. But again, > the RFC doesn't make that limitation clear (enough, IMO), either. > Right, I think that's what I'm driving at. And because of this, we can't take "transit-time" as a given. It is absolutely within the purview of the reconstituted WG to "fix" this by clarifying using current operational realities and acquired experience. An applicability statement, for instance, would not be out of the question. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Problem Statement
On 12/7/22 1:59 AM, Alessandro Vesely wrote: That should be the only deliverable from the wg along with an evaluation of whether the problem is tractable. If it is tractable, the wg should recharter with a plan of how to implement it. Murray said it goes without saying that WGs can fail. It should not be considered a failure to do nothing. That's why just evaluating the problem and coming to consensus on what if anything can be done is useful. It takes the emphasis off of "doing something" just to be doing something. Considering that I'm by far not alone in being skeptical there is anything to be done here, putting the wg back to sleep should be considered a success. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] not removing signatures
> On 7 Dec 2022, at 17:16, Barry Leiba wrote: > >> The purpose of a DKIM signature is, as our original statement put it, to >> make sure that a message from your >> bank actually came from your bank, even if it passed through your alumni >> association. Once it arrives to your >> real mailbox, that signature is not needed. > > As long as the signature is not removed in the alumni case I'm > somewhat less concerned, but... > > In some systems, sieve scripts and other filtering is done *after* the > MUA drops the message in the delivery mailbox. If that drop removes > the signature, that hampers the sieve/filtering process severely. A > sieve "redirect" becomes impossible, and the filtering would not be > able to use the DKIM signature for other purposes either (though it > might be able to rely on the auth-results header field for some > things. > > That's what concerns me. Maybe there’s a split the baby piece where part of the signature is stripped. I’ll be honest, the only bits I really look at are s= and d=. Maybe stripping part (bh?) while leaving the useful bits is a solution. Of course, that is not going to address the replay attack problem at all. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] not removing signatures
On 12/7/22 9:16 AM, Barry Leiba wrote: The purpose of a DKIM signature is, as our original statement put it, to make sure that a message from your bank actually came from your bank, even if it passed through your alumni association. Once it arrives to your real mailbox, that signature is not needed. As long as the signature is not removed in the alumni case I'm somewhat less concerned, but... In some systems, sieve scripts and other filtering is done *after* the MUA drops the message in the delivery mailbox. If that drop removes the signature, that hampers the sieve/filtering process severely. A sieve "redirect" becomes impossible, and the filtering would not be able to use the DKIM signature for other purposes either (though it might be able to rely on the auth-results header field for some things. That's what concerns me. In fact as I wrote in my birth of DKIM post, my original idea was that Bayesian filters could latch on to public keys of good and bad senders. That's not how the ultimate implementation panned out, but it is ahistoric to say that this was only about mail delivery infrastructure and not MUA's. Their participation was always part of the set of possibilities of how DKIM could help. Taking those possibilities out is a huge mistake since we really have little clue how DKIM is being used in the wild. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] not removing signatures
> The purpose of a DKIM signature is, as our original statement put it, to make > sure that a message from your > bank actually came from your bank, even if it passed through your alumni > association. Once it arrives to your > real mailbox, that signature is not needed. As long as the signature is not removed in the alumni case I'm somewhat less concerned, but... In some systems, sieve scripts and other filtering is done *after* the MUA drops the message in the delivery mailbox. If that drop removes the signature, that hampers the sieve/filtering process severely. A sieve "redirect" becomes impossible, and the filtering would not be able to use the DKIM signature for other purposes either (though it might be able to rely on the auth-results header field for some things. That's what concerns me. Barry ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Problem Statement
On 12/7/22 2:59 AM, Alessandro Vesely wrote: ARC is a good forwarding tool. I question the veracity of that. Mostly around -- what I consider to be -- the priming problem of getting a receiving system to trust an upstream system's ARC signature. Its semantic differs from DKIM as it implies no claim of responsibility. So it allows an MTA to forward a message as is, according to user's wishes, without bothering about receiver's policy. I disagree. The forwarding MTA has, can, and will continue to forward messages with or without ARC. What ARC does do is add some information that the downstream receiving MTA /may/ use to make decisions. The presence of ARC itself has no impact on the capability for an MTA to forward messages. That is, for example, if you don't enforce DMARC the receiver is still able to apply DMARC policies using trusted SPF results. In order to override DMARC policies, IMHO, the forwarder should be whitelisted by the recipient: an activity that could be automated, since forwarding to a different recipient requires prior agreement. Forwarding to a different recipient does NOT require prior agreement. Full stop. Any MTA operator can configure their MTA to forward messages to whomever they want completely independently of the downstream receiving MTA's involvement, much less agreement. Murray said it goes without saying that WGs can fail. As someone recently said, science experiments sometimes fail to provide the hypothesized outcome. But it's only a failure if we don't learn something from them. Sometimes learning what doesn't work is more important than learning what does work. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Problem Statement
On Tue 06/Dec/2022 22:52:33 +0100 Michael Thomas wrote: I think that any charter should specifically call out the need for a problem statement. The problem is far more nuanced than the few lines in the proposed charter and I think that the charter should be neutral about whether the problem can be solved because that isn't clear at all. Doing something to do something is how the ARC abomination came about, and we don't need to repeat that kind of behavior. ARC is a good forwarding tool. Its semantic differs from DKIM as it implies no claim of responsibility. So it allows an MTA to forward a message as is, according to user's wishes, without bothering about receiver's policy. That is, for example, if you don't enforce DMARC the receiver is still able to apply DMARC policies using trusted SPF results. In order to override DMARC policies, IMHO, the forwarder should be whitelisted by the recipient: an activity that could be automated, since forwarding to a different recipient requires prior agreement. A problem statement is draft-chuang-dkim-replay-problem. It can be bettered, for example describing specific cases' actual volumes, involvement, damage and remedies. In particular it needs to lay out the problems caused by the specific use case and how they overlap with legitimate use cases, and how complete that overlap is. It should also explore if there are ways to mitigate it with tools other than DKIM. Like for example, why is the sending domain signing spam in the first place? Very much agreed, but that is still a DKIM question. That should be the only deliverable from the wg along with an evaluation of whether the problem is tractable. If it is tractable, the wg should recharter with a plan of how to implement it. Murray said it goes without saying that WGs can fail. Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
