[Ietf-dkim] Re: WG Action: Formed Mail Maintenance (mailmaint) / Commitment
One thing that hasn’t been clear to me: On 21 May 2024, at 9:48, 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. Am I correct that “accepting…for development” means WG adoption of an internet draft that is intended for Standards Track? -Jim ___ 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
Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?
On 5 Feb 2024, at 14:02, Dave Crocker wrote: > On 2/5/2024 1:56 PM, Jim Fenton wrote: >> And you will also provide citations to refereed research about what you just >> asserted as well, yes? > > > Ahh, you want me to prove the negative. That's not exactly how these things > go. You said that the URL lock symbol failed. Asking for research to back that up is not asking for you to prove the negative. I suspect there is research out there that backs up that statement, and I’m just asking for the same amount of rigor that you are asking for. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?
On 5 Feb 2024, at 13:46, Dave Crocker wrote: > On 2/5/2024 1:24 PM, Steffen Nurpmeso wrote: >> I*totally* disagree. >> It is also a matter of education. > > Yeah. No. The standard example is the failure of the URL lock symbol. > > But given your certitude, please provide refereed research about persistent > behavioral change from email header security-related information. And you will also provide citations to refereed research about what you just asserted as well, yes? ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
On 16 Aug 2023, at 10:57, Jon Callas wrote: >> On Aug 16, 2023, at 10:25, Alessandro Vesely wrote: >> >> To repeat my questions, then, would limiting (qualified) DKIM signatures to >> verified accounts diminish replay attacks by any amount? Is this kind of >> solution acceptable? > > There's two reasons that this isn't acceptable. One is that DKIM is > domain-level signing, not user-level signing, and that's been so since the > beginning. DKIM is *intentionally* designed with that as an anti-goal. The > second is the historical use of email, where addresses are not accounts. Deciding whether to apply a DKIM signature based on the submitting user is not the same thing as user-level signing. Signers can use any criteria they want in deciding whether to sign an outgoing message. > In that second historic case, it's not acceptable because there are lots of > cases out there where there are virtual addresses, not really an account, and > yet from time to time a message has to be sent with a `From` of that address. I have lots of virtual addresses. When submitting a message to my outgoing MTA, I still authenticate to it as myself. If my outgoing MTA served multiple users, it should check whether the From address corresponded to my account. In the situation Ale is considering, the decision on whether to sign or not would depend on the submitting user, which is not necessarily the From address on the message. -Jim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
On 15 Aug 2023, at 5:59, Laura Atkins wrote: > But the reality is: bad-actors are going to get through every process. If we > could ID spammers up front and stop them from spamming we’d very likely have > done it already. In this case, they’re using DKIM in a way that was forseen > by the original authors but not treated as something that needed to be > addressed in the protocol. That isn’t quite fair. We thought about replay quite a bit, and didn’t see a viable way of addressing it. Your comment makes it sound like we didn’t care. -Jim (one of the original authors) ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
On 9 Aug 2023, at 2:53, Laura Atkins wrote: > If there are multiple BCCs that implies that whatever is creating the mail > must make individual copies of the message with only the BCC recipient in > that line before it’s signed with DKIM. So for a message with 3 BCCs, there > are 4 separate copies of the message to be created, one with no BCC header > and 3 for each of the BCC recipients. Then each message must be individually > signed. It also seems like the message with no BCC header field would still be eligible for replay, wouldn’t it? This scheme also would depend on DKIM verifiers correlating the signed BCC header field with the envelope-to address of the message. I expect it would take quite a while for verifiers to migrate to code that does this correlation. A better scheme (but not much better) might be to define an Envelope-to: header field, but that also has the verifier problem. And all of these would break recipient-side forwarders (e.g., alumni addresses, role-based addresses). -Jim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Proposals for tolerating mailing list modifications
On 4 Aug 2023, at 11:57, Dave Crocker wrote: > On 8/4/2023 11:51 AM, Jim Fenton wrote: >> I was referring to draft-chuang-replay-resistant-arc-07, not what is >> mentioned in the subject line. It refers to RFC 8617 which is experimental, >> although it lists it as an informative rather than a normative reference >> which I think is incorrect. > > You think there is a problem with having a nascent draft specification refer > to -- or even rely on -- a published, experimental specification? Really? > > I don't recall that being a problem historically nor against any IETF > policies, rules, or the like? Perhaps you can elaborate on your concerns and > the historical basis for them? The charter calls for a standards-track specification by December. It would seem problematic if it has a normative reference to an experimental specification. But a call for adoption has not been issued yet, so perhaps this is jumping the gun. -Jim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Proposals for tolerating mailing list modifications
On 4 Aug 2023, at 11:53, Dave Crocker wrote: > On 8/4/2023 11:39 AM, Jim Fenton wrote: >> I’m even less clear on draft-chuang-mailing-list-modifications. Does it have >> to do with the currently chartered work > > > DKIM WG charter: > >"it will produce one or more technical specifications that propose >replay-resistant mechanisms." > > I don't have an opinion about the quality or utility of this I-D, but it has > quite a few references to replay, including: > >"The validation results in this specification are orthogonal to the >results indraft-chuang-replay-resistant-arc ><https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/> . >In addition to better supporting DMARC in the presence of >mailing-list modifications, this specification enables attribution >of malicious content back to the author. However this specification >is vulnerable to replay much like DKIM and ARC. >draft-chuang-replay-resistant-arc ><https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/> >validation is tolerant of header and message body modifications but >unable to provide attribution." > > > This would seem to answer you question. That is, it has text indicating > relevance. > > You might disagree that it's relevant. That's fine, but to promote useful > discussion, details are needed. > > From you. > > That is, to the extent that you disagree about its relevance, it will help to > hear specifics, rather than your asking a generic question that throws a > burden of proof back on the document author, without providing them any > indication what criteria you are applying here or any detail about why you > think it not relevant. I was not disagreeing with anything. I was asking a question. That’s all. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Proposals for tolerating mailing list modifications
On 4 Aug 2023, at 11:43, Dave Crocker wrote: > On 8/4/2023 11:39 AM, Jim Fenton wrote: >> concerns about creating a dependency on something experimental > > > I missed the details about a 'dependency'. > > What is it that would be dependent and what is it it would be dependent on? I was referring to draft-chuang-replay-resistant-arc-07, not what is mentioned in the subject line. It refers to RFC 8617 which is experimental, although it lists it as an informative rather than a normative reference which I think is incorrect. -Jim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Proposals for tolerating mailing list modifications
On 4 Aug 2023, at 11:31, Tim Wicinski wrote: > Michael > > Actually it appears draft-chuang-replay-resistant-arc is listed in the > charter (I had to check for myself). > We can have the larger ARC discussion but I'll want to talk to Murray and > Laura on that also. Agree with Mike’s concerns about creating a dependency on something experimental, but I’m even less clear on draft-chuang-mailing-list-modifications. Does it have to do with the currently chartered work or was it shared with the list because it relates to DKIM? -Jim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement
Very nicely put, Scott. I was also thinking this action ought to be be initiated by someone else in authority, probably either Tim or Murray, if it is appropriate. The timing of this warning also unfortunately makes it seem like it comes at the behest of another working group participant, while it is of course the WG chairs’ (or AD) responsibility to make this determination. -Jim On 28 Mar 2023, at 22:21, Scott Kitterman wrote: > I am attempting to tread carefully here. My success in doing so is > historically quite mixed, so if I fail, apologies in advance. > > In my view Micheal has challenged your approach to some of your decisions in a > very sharp manner (which I don't support). In general, I think if a working > group chair is party to a dispute, it's better for the other chair to address > it. When you are both a party to the dispute and use your authority to > address it, it (at the very least) creates a potential perception of > impropriety. > > If we imagine a world where Michael's accusation is literally true and you > were trying to shut down any discussion of alternatives to some pre-conceived > result you've already decided on, this is precisely what the next step would > be. > > My request is that you withdraw this and ask Tim to send it instead if he > thinks it's appropriate. > > Personally, I found your response to him in Message-Id: > <86ff4071-0720-4cde-9815-f7c472171...@wordtothewise.com> pretty harsh, > particularly when two days later in Message-Id: b323-115e5196b...@wordtothewise.com> you agreed with me that it was reasonable > to wait for the next revision of draft-chuang-dkim-replay-problem before > working on it further. > > Based on what you've said in those two messages, I understand your direction > to the working group is to only talk about specific text changes to the non-WG > draft, but you also agree there's really not much point in doing so. > > Rather than take steps to push a contributor with a lot of relevant domain > knowledge out of the group (which is precisely what this is, intended or not), > I would encourage the chairs to work towards reducing the emotional energy in > the group. I think that would be more useful than process threats. > > I am honestly wondering if I want to keep doing this. > > Scott K > > On Tuesday, March 28, 2023 5:31:07 AM EDT Laura Atkins wrote: >> Dear Michael, >> >> Your message of 27 March quoted in its entirety below, included _ad hominem_ >> attacks against another participant. _Ad hominem_ is a fallacious form of >> argument wherein the person arguing attacks the person holding an opposing >> position, rather than attacking the position itself. This is not >> acceptable, and you have been warned before. I contacted you off-list on >> behalf of the chairs, under the procedures in BCP 25, but you have refused >> to take what we regard as rectifying action. >> >> Accordingly, please understand this message as a formal warning under the >> procedures of BCP 25 that, if we observe continued behaviour of the sort >> you have exhibited, we shall suspend your posting privileges to the >> dkim-ietf mailing list for 30 days. Behaviour of the sort includes >> anything that we believe to be needlessly personalized, and especially >> includes _ad hominem_ forms of argument. We will also treat returning to >> points that have been closed without raising new arguments as attempts to >> disrput the functioning of the Working Group. >> >> We will act without further warning in such an event. >> >> If we take that action, and, after restoration of your privileges, we >> observe you to return to disrupting the work of the group, we shall >> undertake action under BCP 25. >> >> Sincerely, >> >> Laura (for the chairs) >> >>> On 27 Mar 2023, at 17:04, Michael Thomas wrote: >>> >>> On 3/27/23 8:46 AM, Scott Kitterman wrote: On March 27, 2023 3:10:40 PM UTC, Laura Atkins > wrote: > It seems to me a history of what did work / didn’t will go into document > 4 or the reasoning for document 3. My current preference is for the > discussion to not be in the problem statement. My reasoning is that > there will be discussion about what didn’t work and why it didn’t work. > I expect that there will be quite a bit of back and forth to capture > the details of why something didn’t work - including the adaptations > that the attackers made to the changes. This, to my mind, is the job of > the working group: to look at the current status, discuss where the > holes are and if they are protocol holes or if they are best practice / > implementation holes. > > On a more practical point, we have a month to finalize the problem > statement. No one has proposed language to include in the problem > statement about what has worked and what hasn’t worked. Given the > current state of the group, I simply don’t think we have the time to > put this into the problem statement and get it out in
Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement
On 25 Mar 2023, at 8:57, Michael Thomas wrote: > Somebody brought up that this could turn into a research project. Frankly I > think that is highly likely the case and is why rechartering was so > problematic. Since M3AAWG can't figure it out with lots of inside the > industry information, what makes anybody think the wider community would have > better insight which is not speculative because it has been tested and known > to work? It speaks volumes that they didn't have a solution in mind and bring > it to IETF to vet in the wider community. That sure sounds like a research > project to me. It may indeed be a research project, but I’d rather see that happen in IETF or some similarly open venue rather than to have it happen in a closed forum like M3AAWG, which brings the risk that the proposed solution will meet the needs of only the large domains that are M3AAWG members, and not the small ones that aren’t. -Jim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM replay problem statement
On Mar 9, 2023 at 15:55:20 MST, Michael Thomas wrote: On 3/7/23 2:46 PM, Jim Fenton wrote: Section 3.4: I would always expect an inbound filtering service to do SPF/DKIM checks and apply an Authentication-Results header field with the result. Are there any that don’t?I don't think we should count on Auth-res being there or not. As I mentioned previously, there is a wealth of possible meta information produced in the act of verification that is not necessarily transported by the Auth-res header. Frankly, I'm not sure why Auth-res needs to be brought up at all -- by the time it is applied, it has already fallen into the black box of the receiver of which we know little about. The inbound filtering service is acting on behalf of a recipient domain, so I expect that it would have some way to signaling any authentication information that domain might need that it interferes with (such as the sending IP address) by virtue of receiving the message on their behalf. Authentication-results is one way that is often done, but perhaps I was being too specific in citing it. -Jim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
[Ietf-dkim] DKIM replay problem statement
To get things going, here are a few comments on draft-chuang-dkim-replay-problem-01: Section 1.1: “…list DKIM records…”: this should probably say that they sign outgoing messages with DKIM. “validates the message”: This sort-of implies that messages without DKIM signatures are somehow invalid. We had used the term “email authentication” but a more accurate term from RFC 6376 would be “claims some responsibility for the message”. “DKIM is one such identity”: DKIM isn’t an identity. A d= domain in a valid signature is an identifier, however. “Bcc header field”: There is no Bcc header field. That would contradict the intent of bcc. Section 1.2: “Mailing lists…May append text to the Subject header and at the end of the content.” Suggest describing this as modifying the Subject header field or the content. Section 2: “Spammer may intentionally leave out certain headers”: RFC 6376 (section 5.4, last paragraph) recommends that signers sign all end-user visible header fields to avoid exactly this problem. This is really low-hanging fruit for a best practices document. I have no sympathy for domains that don’t sign (or over-sign, if they’re not present) these header fields and then suffer replay attacks. Section 3.3: “Losing control of their private key”: There shouldn’t be a single private key in this situation; the domain should be delegating a different selector to the outbound filtering service. If they can’t trust the domain to manage a delegated signing key, they’re probably not suitable to be an outgoing filtering service either. This situation also exists for bulk senders that sign on behalf of the author domain as well (section 3.2), but isn’t discussed there. Section 3.4: I would always expect an inbound filtering service to do SPF/DKIM checks and apply an Authentication-Results header field with the result. Are there any that don’t? Section 3.5.1: Why is this a subsection of Mailing list? This is an entirely different use case. “Updating the envelope from address (MAIL FROM)”: Not necessarily. The classic example is if you set up a .forward file on a Unix system, and the message is forwarded with the original MAIL FROM. This use case has gotten a lot more complicated in recent years, with some forwarders doing increasingly aggressive things to messages including, in some cases, message modification. —— While our chair has suggested we not focus on the solution space at this point, I have a couple brief comments on section 4. 1. Envelope To address in a header field: Unless the envelope-to address is a single address, this is a privacy violation. For the same reason, envelope-to is omitted from Received header fields when there is more than one recipient. 2. As an additional “con”, a DKIM signature cache would only benefit large recipient domains, and provide no benefit to small ones. -Jim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Misuse of antiforgery protocols
On 13 Dec 2022, at 9:06, Evan Burke wrote: > On Tue, Dec 13, 2022 at 8:45 AM Jim Fenton wrote: > >> Is there anything that you can say about the types of domains whose >> reputations are suffering as a result of replay attacks? Are they, for >> example, small consumer mailbox providers, email sending providers, or >> services that for some reason allow third parties to send (presumably >> transactional) email through their servers? >> > > Predominantly ESPs, but really anyone with substantial sending volume and > good reputation on the d= domain. ESPs seem to be the primary target > because they tend to have the highest sending volume, so the attacker can > send more replays before reputation and deliverability degrade. I’m not an ESP, of course, but it seems like they need to do more vetting of new customers (like perhaps manually reviewing their mailings) until they are convinced those new customers are good actors. I realize this is an expensive thing to do, but the ESPs are, after all, loaning their good email reputation to their customers and they need to protect that. Because of relays, this needs to be done even if those customers appear to be sending to a relatively small list of recipients. I am less sympathetic to this problem if it is primarily the result of insufficient diligence on the part of ESPs. -Jim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Misuse of antiforgery protocols
On 13 Dec 2022, at 17:00, Michael Thomas wrote: > Which brings up a question: even though they pass on DKIM they should fail on > SPF, right? For transactional email that seems like a big old red flag, right? Some people use receive-side forwarders (e.g., college alumni addresses) to have a consistent email address if they change ISP. That will, completely legitimately, cause SPF failures on transactional email. -Jim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Misuse of antiforgery protocols
On 12 Dec 2022, at 12:11, Evan Burke wrote: > These attacks were very narrowly targeted; the vast majority of DKIM replay > spam this year has been sent to just a few of the largest consumer mailbox > providers. In that context, lack of awareness of the problem is a poor > argument against trying to solve it. This is interesting and surprised me a bit. I had expected that the senders of the messages being replayed were the large consumer mailbox providers, because it would be easy for spammers to hide in a large crowd and because the reputation of the large mailbox providers is (I expect) fairly bullet-proof just because of their size. Is there anything that you can say about the types of domains whose reputations are suffering as a result of replay attacks? Are they, for example, small consumer mailbox providers, email sending providers, or services that for some reason allow third parties to send (presumably transactional) email through their servers? -Jim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Taking Responsibility
On 9 Dec 2022, at 17:00, Michael Thomas wrote: > On 12/9/22 4:53 PM, Dave Crocker wrote: >> On 12/9/2022 4:41 PM, Michael Thomas wrote: >>> Considering that I was one of three original designers >> >> You worked on Domainkeys? >> >> When Yahoo asked me to be one of their outside reviewers, for their initial >> work, I don't recall your being involved. >> >> This was considerably before there was the first, direct effort to bring >> things to the IETF. >> > Domainkeys and IIM were convergent evolution. IIM was actually published > first. I produced the first DKIM implementation followed by Murray a day or > two later. DomainKeys and IIM both preceded IETF’s DKIM effort and neither of them is DKIM. The semantics and motivation behind a DKIM signature were determined by IETF consensus when it was standardized, and isn’t necessarily what the semantics and motivation behind a DomainKeys or IIM signature were. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On 8 Dec 2022, at 7:25, Murray S. Kucherawy wrote: > On Thu, Dec 8, 2022 at 12:56 AM Laura Atkins > 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. >> >> >> I think a checkpoint / review is a good goal for the group. >> > > This seems like something reasonable and easy to add. > > Any objections? I’m fine if the revision to best practices is scoped to the replay problem. This was presented to dispatch as a narrowly scoped problem statement, and the rechartering result was decided on that basis. If this were to evolve into a “let’s think about DKIM best practices” more generally, it will get bogged down. -Jim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Misuse of antiforgery protocols
Of course, ARC replay will also need to be addressed. But that’s a job for the DMARC working group. -Jim On 30 Nov 2022, at 8:31, Barry Leiba wrote: No one wants it to be the permanent solution, and ARC is one alternative proposal. But “From munging”, while ugly and not without down-sides, is something that can be done unilaterally and works. ARC and related mechanisms require widespread adoption in order to be effective. Barry On Wed, Nov 30, 2022 at 9:03 AM Mark Alley wrote: That's a question I've always had on this topic. Is 5322.FROM an acceptable long-term workaround for DMARC enforced domains? The community in general seems to be split on 5322.FROM munging and it's use in practice. On 11/30/2022 12:41 AM, Barry Leiba 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. And for mailing list that don't re-write the From address, the issue isn't that the sender can't post. It's that subscribers whose domains enforce a "p=reject" policy will not get the posts, and will eventually become unsubscribed because of the bounce messages their domains generate. Neil wouldn't see the harm: others would. It's insidious. Barry ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Misuse of antiforgery protocols
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. -Jim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)
On 26 Nov 2022, at 15:20, Barry Leiba wrote: > We have to decide whether it's worth breaking that use case in order > to address the replay situation. My opinion is that it's not -- > because, as I say, I rely on that use case extensively. My system > would have to change *significantly* in order to work around that. On 25 Nov 2022, at 2:26, Laura Atkins wrote: > And, I think most importantly: will this recommendation by the IETF have any > impact whatsoever on the groups currently using DKIM replay as a way to get > past (some) filters? I don’t see how it will, most of them are using their > own email addresses / servers to collect the replayed messages and then > sending the messages out through their own systems. Even if Google and > Microsoft and Yahoo and the other top 20 mailbox providers start stripping > DKIM headers, the attackers will be able to find some service somewhere that > doesn’t. Worst comes to worst, they stand up a MX on an EC2 instance and run > their own code to collect the mail. We should use the criteria that the FDA establishes for remedies: “Is it safe and effective?” Not Safe: It’s not safe because it breaks Barry’s use case above, and others have pointed out MUA usage of the signature. Not Effective: Attackers can easily circumvent this by running their own MX (if they don’t do that already) as Laura and others have pointed out. We should move onto better ideas. -Jim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)
On 21 Nov 2022, at 16:07, Jon Callas wrote: >> On Nov 21, 2022, at 14:01, Dave Crocker wrote: >> >> On 11/21/2022 1:56 PM, Murray S. Kucherawy wrote: >>> I don't want to get into implementation discussions before we even have a >>> charter, but I'm curious about how this could be made effective. >> >> I'd count it as a simple tool that might have incremental benefit. >> >> Simply give guidance that an MDA SHOULD remove the DKIM signature, unless >> there is a local arrangement with the recipient not to. (Obviously the >> local detail could swap the default the other way.) >> >> I would expect anything more elaborate to be in the range of diminishing >> returns and, therefore, not worth the complexity, effort, etc. > > As another original author, it was hard for me to understand what this was > talking about when the discussion first came up. I even considered replying > to this thread asking something like, "isn't replay just sending the message > again?" before I understood. > > I really like the guidance that an MDA SHOULD remove a DKIM signature. I have > memories that we discussed just that even at the time, for a number of > reasons. > > This is a fine solution to this problem. The replay issue just goes away if > the header lines are removed. I disagree with Jon (and Dave) on this. Spammers are notably agile — if some mechanism they have been using stops working, they quickly adapt and develop a workaround. In this case, they only need to arrange to have the signed message relayed to an MTA they control, and their problem is solved. In many cases they probably collect the signed messages from their own MTAs already. There is only a very indirect benefit for the very large number of DKIM-aware MTAs to change their behavior and remove DKIM signatures at delivery. This will take a VERY long time to happen, and the problem persists in the meanwhile (and the above adaptation on the part of spammers takes place as well). > It also addresses my long-standing complaint that DKIM is not supposed to be > a tracking and authenticity mechanism. Moreover, this is a much better > solution to my complaint than anything anyone has come up with, including my > eccentric foot-stamping about keys. This came up in the context of the use of DKIM signatures on leaked email messages to authenticate the leaked content. That is not the problem we’re trying to solve here. -Jim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)
On 20 Nov 2022, at 11:08, Dave Crocker wrote: > On 11/11/2022 7:19 AM, Murray S. Kucherawy wrote: >> I think you've hit on possibly the most interesting part of this: In RFC >> 6376, we said "You're taking some responsibility for this message... and oh, >> by the way, it could get replayed, and your claimed responsibility extends >> to that case as well". I don't know that we underscored the latter very >> much then or since. > > > At the time DKIM was first developed, we knew that replay was possible. It > was deemed a lesser concern. Back then. > > But the "by the way" that you've added was /not/ part of the thinking then > and it occurs to me that a) no it was not and is not intended, and b) this > might argue for *having MDAs remove DKIM signatures...* a) It’s difficult to say what was and what wasn’t part of the thinking back then. My recollection differs, but what we didn’t have then is the current experience on how DKIM-based reputation systems are used. b) This assumes that the attackers (replayers) only have access to the messages at delivery, and don’t operate their own MTAs. This is of course not a good assumption. -Jim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group
On 9 Nov 2022, at 13:08, Barry Leiba wrote: > Murray is looking at re-opening the DKIM working group, chartering it > to work on replay mitigation. IIRC the result from Monday’s dispatch session was to go ahead and charter the working group without a BOF. It seems to me that the discussion on this thread in the last few days points to the need for a BOF prior to chartering. Given that IETF 115 just ended, it probably ought to be an interim BOF before IETF 116. -Jim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group
> On Nov 12, 2022, at 8:32 AM, Roland Turner
> wrote:
>
>
>>
>> On 11/11/22 23:09, Murray S. Kucherawy wrote:
>>
>>
>> More concerning to me: The IETF has previously taken the position that the
>> market will figure out spam and phishing, and therefore consideration of
>> protocol solutions should be deflected. DMARC was the result. I feel that
>> we leave this to the market, and that industry, at our own peril. I think
>> we should give this a serious look before rejecting it outright.
> Are you able to state concisely why DMARC was a harmful outcome, assuming
> that's your intended meaning ("peril")? From my admittedly somewhat
> bystanderish perspective, DMARC looked like a great success, particularly
> after IETF repeatedly failing for more than a decade[1].
>
I would give my opinion, but that’s off-topic for discussions of the replay
problem.
-Jim
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Adding an aim= tag to DKIM Signature Tag Specifications
On 5/11/20 10:30 AM, Dave Crocker wrote: > On 5/11/2020 10:21 AM, Alessandro Vesely wrote: >> The question is, what responsibility is being claimed? > >> Tagging keys with aim= would allow senders to choose an appropriate >> selector >> under different circumstances. > > > If signers want to have a standardized means of indicating the > fine-grained semantics behind their signature, they can do that > without modifying DKIM. > > Rather, define and use a header field that specifies DKIM signing > policy. Cover it with the DKIM signature, of course. If this is expressing semantics for the DKIM signature, it's also likely that there are going to be multiple DKIM signatures on the message with different semantics. There might then be multiple instances of the header field, and it would be difficult to associate each signature with the appropriate semantics header field, except in the specific case where there is only one specific semantics header field and all signatures use either that or the default. There might also be the situation where a domain wants to delegate a key to a third party that can only have a subset of semantics, e.g., "this was sent by our advertising partner" vs. "this comes from our own staff". That's a reason to tag the key; otherwise, it would be preferable to tag the signature itself. This would be an extension, not a modification of DKIM. > > The only interesting part of this task is deciding on a standard set > of policy labels. > > Oh, and then figuring out why and how they are useful to provide... I'm also not clear on what the aim= tag would be asserting, why it would be trustable by a verifier, and how this would be useful to a verifier, and would like to hear more about that. -Jim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Thinking About DKIM and Surveillance
On 10/2/19 12:29 PM, Jon Callas wrote: > I know that I've written about this before, so please bear with me a bit. A > continuing concern of mine is the way that DKIM contributes to overall > surveillance smog that the Internet has. > > When we designed DKIM, this was something we considered; it was a concern. It > wasn't so big a concern that we thought it should derail DKIM, and it wasn't > even a concern when it was taken over by the IETF. Nonetheless, it was an > issue, is an issue, and becomes a bigger issue nearly every day. The most > notorious failure here is the Podesta email dump, where the stolen emails > were verified against the DKIM signatures. This is precisely what we didn't > want to happen -- that DKIM was used for things beyond fighting inauthentic > emails. We ought to do something, the question is what. Yes, we definitely considered privacy with respect to DKIM. But my recollection is different: I don't remember discussion of the potential forensic use of DKIM signatures to provide unintended non-repudiation of leaked emails. I also wouldn't describe the presence of such signatures on email messages to be surveillance -- although it does contribute to the effectiveness of surveillance done by other means. The type of surveillance we were discussing at the time was the potential that the verification of a DKIM signature might give the sender information on the location of the recipient (by observing the DNS requests at the point where the key record is hosted). Use of different selector names could also differentiate requests on behalf of a particular target. I believe this concern was addressed by the observation that the signature verification would typically be done by the recipient's mail provider, and not by the recipient themselves. I don't doubt that others (particularly Jon) thought more thoroughly than I about privacy concerns such as this. -Jim (who will read the article soon!) ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
[Ietf-dkim] X-Google-DKIM-Signature header field
[resending because I needed to correct subscription address. Apologies for duplicate if the moderator approves the original.] I recently got a "welcome" message from a list.nist.gov mailing list that is apparently hosted on Google infrastructure. I notice it wasn't DKIM signed, but did have a X-Google-DKIM-Signature header field that looked like a normal DKIM signature with d=1e100.net (one of Google's many domains). Apparently Google doesn't intend that I rely on this signature for anything, but does anyone know why they aren't applying a normal DKIM signature from 1e100.net here? -Jim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: Last Call: draft-klensin-rfc2821bis
Dave Crocker wrote: I keep trying to understand why the SMTP use of records should be any different than its use of A records. Haven't heard a solid explanation, nevermind seen consensus forming around it. It seems there are two ways of looking at this: (1) records in the IPv6 world should do exactly same things as A records in the IPv4 world, so SMTP should look for an record in the absence of an MX record, just as A records are used in the absence of MX records. (2) Although some SMTP servers will continue to be found through A records for legacy reasons, there is no longer a good reason for any new server not to have a published MX record. SMTP clients (senders) will, of course, need to continue to look up A records, but since there is currently no significant use of records for email routing, we should not perpetuate this legacy in IPv6 as it is in IPv4. These are both reasonable positions, but I'm in camp (2). The additional use of records for email address resolution would add complexity to at least some implementations and test cases, and it something that should never be needed: v6 mail handlers will just publish MX records. There is probably a small DNS efficiency argument as well, especially if the MX, A, and requests are not made together. I wish that 2821bis made a stronger statement deprecating the use of A records for email address resolution, but it seems not to have been the consensus to do so. Writing a separate BCP on this point is not a good use of anyone's time. -Jim ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: Pingsta Invitation
I did sign up some time back (careful to use a password distinct from everything else, and making sure that what little information I put there is already visible somewhere else) just to have a look. It appears to have only about 50 members so far. It does appear to be a legitimate attempt at a niche social networking site targeting networking engineers, but I'm not sure we need one. -Jim Fred Baker wrote: Does anyone know who this is or what it is about? Begin forwarded message: From: Pingsta Registration [EMAIL PROTECTED] Date: March 24, 2007 8:31:52 AM GMT+01:00 To: Fred [EMAIL PROTECTED] Subject: Pingsta Invitation Fred, As an Internetwork expert, we would like to invite you to join Pingsta. Pingsta is a new experience in social networking that provides you with a platform to share your passion for internetworking, expand your industry network, and express yourself like never before. By actively contributing to Solvr - Pingsta's innovative user-generated internetwork intelligence repository - members extend their intellectual legacy and partake in Pingsta profit-sharing. Pingsta is exclusive to internetwork experts, membership is by invitation-only, and it only takes a minute to sign up. Here's your personalized invite-key: http://www.pingsta.com/[EMAIL PROTECTED]invitekey=eb108e15cd12c9b500695 Sincerely, The Pingsta team ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Currency Exchange in Montreal
Clint Chaplin wrote: My hotel (Intercontinental) is quoting 1.054 for their currency exchange. Knowing the current wholesale exchange rate, this means that the hotel is charging about 7% premium. Anybody run across something better around the convention center? Thanks. There are a number of banks around, such as the CIBC about a block up Rue St. Urbain (which runs along the East side of the convention center). Haven't checked their rates, but I typically do better at banks. -Jim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Value of Reputation
John Leslie wrote: Nathaniel Borenstein [EMAIL PROTECTED] wrote: On Dec 24, 2005, at 4:09 PM, Douglas Otis wrote: Reputation remains the only solution able to abate the bulk of abuse. ... I think most of us pretty much agree about the critical role of reputation. I've noticed a lot of what I call lip service about the critical role of reputation. To say this differently, many folks seem to think you can choose a reputation system almost at random, and it's sure to improve your signal/noise ratio, unless you've chosen the wrong one. (which, I suppose, is a tautology...) But, in my view, we have no basis to choose the right one unless we have a good understanding of what it measures and a workable idea of how to end run when it falsely rejects good messages. I completely agree that reputation has a critical role (although accreditation is important in many situations, as Phill has pointed out, and should not be ignored). However, I have come to believe that there is a great deal of subtlety below the surface of any good reputation system: - Preventing abusers from gaming the system to get good scores - Preventing attackers from damaging the reputations of others - Defending the reputation system against legal actions from those who feel they have been hurt - Making it all work within the law, considering privacy laws, restraint of trade, and so forth, considering that the laws governing this vary by jurisdiction For this reason, I don't think the operation of reputation systems themselves should be defined by IETF; different users will have different needs. However, standard protocols for communicating with reputation systems will be needed, and this is a very important area for IETF to address. Transaction rates for lookups will be high, and careful protocol design is needed. The use of standard protocols in this area will allow clients to pick a suitable reputation service, and to change services without changing their infrastructure. Both reporting and query protocols will need to be defined. Much of this applies to accreditation services as well, although there are some different requirements (negotiating an accreditor to use between sender and recipient/verifier, for example). -Jim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Value of Reputation
John Leslie wrote: The question of standards for reputation and accreditation, IMHO, deserves IETF work and could deliver great value. But to be clear, I do not think it belongs in DKIM. I strongly agree. By CCing the ietf-dkim list on my message I didn't mean to imply that the work belongs there. -Jim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Dave Crocker wrote: We have agreed to the addition of an enhancement that provides a good alternative to the existing set of two algorithms. That is quite different from tossing out over-the-wire backward compatibility. I have not seen the group agree that a sender of an (ESTG) DKIMv1 signature will fail with an (IETF) DKIMv2 validator. Dave, 'nowsp' canonicalization does not exist in DKIMv2 (-base-01). It was eliminated, rather than deprecated, because it created a vulnerability. While some -base-01 verifiers may implement legacy nowsp support, a fully compliant -base-01 verifier may not work with a -base-00 signature that uses nowsp canonicalization. -Jim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
The IESG wrote (quoting the proposed DKIM charter): Since experimentation resulted in significant Internet deployment of these specifications, the DKIM working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are necessary for the success of the specifications. Ted Hardie wrote (quoting an XMPP charter): Although not encouraged, non-backwards-compatible changes to the basis specifications will be acceptable if the working group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. I don't really see much difference between the two sentences. In one case, the bar is necessary for the success of the specifications while in the other case it's required to meet the group's technical objectives (and hopefully the group's technical objectives are for the success of the specifications). In one case, non-backwards-compatible changes are not encouraged, while in the other, every reasonable attempt is made to keep things compatible. It's a significant precedent that IETF charters have included language of this sort when there has been a deployed base at the time the WG is chartered. But can someone explain what's different in this wording that warrants departing from the version on which there seems to be rough consensus? -Jim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
