Re: [dmarc-ietf] Two basic Issues to address to help complete DMARCbis
> On Apr 23, 2023, at 4:17 PM, Dotzero wrote: > > On Sun, Apr 23, 2023 at 1:20 PM Hector Santos > mailto:40isdg@dmarc.ietf.org>> wrote: >> >> With each year, that "temporary hack" becomes the new normal and it >> will be harder to clean up. It is not the right way and I don't its >> too late to reverse. However, it has been 17 years and DMARCbis is >> not finished without some clean up in this area. > > It HAS NOT been 17 years for either DMARC (first published in 2011 and first > submitted to IETF as informational in 2015) or DMARCbis. Let's at least use > publicly available data points for time frames rather than time frames pulled > out of thin air. Wow. I’ll apologize for the confusion. Allow me to paraphrase it: “However, it has been 17 years since the evolution of SSP, DSAP, ADSP, ATPS and now DMARCbis and unfortunately it is not finished without some clean up in this area.” A little better, I hope. I see all of the as a DKIM Policy Model and DMARC just happens to be current rendition of the concept. I have worked with all of them and before that, we did a real security analysis and requirements work. Not sure if you participated in this early DKIM wg work. >> >> I can understand why DMARCbis's editor does not want to document >> rewrite, but imto, can't be ignored anymore. The details of a >> rewrite can be quickly outlined. To help the RFC process, maybe >> DMARCbis could refer to the Functional Specifications of SSP (RFC5016) >> Section 5.3, Item 10 which basically reinforces the idea that local >> policy ALWAYS prevails and it is quite possible there will be >> undesirable tearing down of secured submissions. One possible >> mitigation is to replaced it with a secured rewriter with a p=reject >> policy. > > SSP is long gone and failed. Referencing something which failed to gain > support many years ago is also not a path to go down. I referenced the Functional Specification for SSP (RFC5016), not the SSP itself which was still only in draft form. https://datatracker.ietf.org/doc/html/draft-allman-dkim-ssp-02 The development and point of RFC4866 and RFC5016 was to help Eric and Jim create SSP and thats when Levine’s ADSP stepped in. From a software engineering standpoint, the documents provided the security analysis and requirements to make a "SSP” protocol. It does not change the original analysis or requirements. Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) https://datatracker.ietf.org/doc/html/rfc4686 Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol https://datatracker.ietf.org/doc/html/rfc5016 Please review these, especially Section 5.3 of RFC5016. I was sort of helping DMARCbis. It can refer that provision to maybe justify the rewrite. After all, it was a game changer in all this when it was added. — HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Two basic Issues to address to help complete DMARCbis
On Sun, Apr 23, 2023 at 1:20 PM Hector Santos wrote: > On 4/23/2023 6:10 AM, Alessandro Vesely wrote: > > > > Meanwhile, digressions about ATPS and similar schemes can help > > casting some light on future evolution. From: rewriting cannot be > > the final solution; it is a temporary hack. Digressions don't slow > > down the publication, as discussions about actual text quickly > > prevail. They are just a mean to help convergence toward a common > > vision of the future. > > With each year, that "temporary hack" becomes the new normal and it > will be harder to clean up. It is not the right way and I don't its > too late to reverse. However, it has been 17 years and DMARCbis is > not finished without some clean up in this area. > It HAS NOT been 17 years for either DMARC (first published in 2011 and first submitted to IETF as informational in 2015) or DMARCbis. Let's at least use publicly available data points for time frames rather than time frames pulled out of thin air. > > First, Section 4.4.3 should have text on using extended tag methods to > provide 3rd party authorization methods. Just add the RFC 6541 > abstract or version of it: > No! Supporting and referencing an experimental specification which has never gotten significant traction is the wrong way to go. If you believe that ATPS is the right path then YOU should work to attract a wider range of participants to use ATPS and then provide data back to IETF, whether through an ATPS working group or a DKIM working group that is chartered to undertake that work. > > ATPS [RFC6541] is an experimental specification proposed which > adds a extended tag "atps=" allowing > advertisement of third-party signature authorizations that are to > be interpreted as equivalent to a signature > added by the administrative domain of the message's author. ATPS > was designed for ADSP. There is interest to > apply this tag to DMARC to help deal with unchecked but > authorized resigners false positives. > You don't even need a working group at this point to validate that ATPS works and that it can scale in a workable manner. It has not been shown that ATPS scales with regard to adds and deletes of individual tags. As you quite rightly point out, ATPS was designed for ADSP, not DMARC. I have no problem if you and others wish to experiment but you should do your experiment first and then seek agreement from the wider community before it gets embedded in another specification. Why should ATPS be granted special consideration vs other proposals out there? It shouldn't. > > Second, there are possible outcomes with members using restrictive > domains: > > 1) Legacy MLS/MLM, unaware of protocol, unchanged author domain, > submission mail integrity is broken due to long time practice of body > and subject changes, can cause members of a list to be > auto-unsubscribed when their receivers begin to honor p=reject and > reject mail integrity DKIM failures. > > 2) Protocol Awareness, honoring the policy, constraining subscription > and submissions to unsecured submissions. Restrictive domains not > acceptable for list submissions. Note: It is possible to allow a > Read-Only List Member concept. > > 3) Protocol Awareness, not honoring policy and tearing down the author > security, replacing with unsecured distribution. > > The correct way for any protocol is to close security loopholes. In > this case, recommend #2 using Subscription and Submission controls. > Let the author domain figure it out. DMARCbis MUST recognize if the > intent of the domain is to clean up their brand, by implementing hard > failure rejects at both SPF and DMARC, then it should recommend > handlers SHOULD honor the policy of the domain or be prepared for the > possible false positives. > > I can understand why DMARCbis's editor does not want to document > rewrite, but imto, can't be ignored anymore. The details of a > rewrite can be quickly outlined. To help the RFC process, maybe > DMARCbis could refer to the Functional Specifications of SSP (RFC5016) > Section 5.3, Item 10 which basically reinforces the idea that local > policy ALWAYS prevails and it is quite possible there will be > undesirable tearing down of secured submissions. One possible > mitigation is to replaced it with a secured rewriter with a p=reject > policy. > SSP is long gone and failed. Referencing something which failed to gain support many years ago is also not a path to go down. > I don't think the above will take long to do and I believe will help > resolve the conflict. > It doesn't resolve the conflict. As I stated above, if you believe in ATPS then you need to attract a wider range of participants for your experiment, including sending domains, receiving domains and intermediaries (and not just mailing lists). Repeating "this solves the problem" is not data. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailma
[dmarc-ietf] Two basic Issues to address to help complete DMARCbis
On 4/23/2023 6:10 AM, Alessandro Vesely wrote: Meanwhile, digressions about ATPS and similar schemes can help casting some light on future evolution. From: rewriting cannot be the final solution; it is a temporary hack. Digressions don't slow down the publication, as discussions about actual text quickly prevail. They are just a mean to help convergence toward a common vision of the future. With each year, that "temporary hack" becomes the new normal and it will be harder to clean up. It is not the right way and I don't its too late to reverse. However, it has been 17 years and DMARCbis is not finished without some clean up in this area. First, Section 4.4.3 should have text on using extended tag methods to provide 3rd party authorization methods. Just add the RFC 6541 abstract or version of it: ATPS [RFC6541] is an experimental specification proposed which adds a extended tag "atps=" allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author. ATPS was designed for ADSP. There is interest to apply this tag to DMARC to help deal with unchecked but authorized resigners false positives. Second, there are possible outcomes with members using restrictive domains: 1) Legacy MLS/MLM, unaware of protocol, unchanged author domain, submission mail integrity is broken due to long time practice of body and subject changes, can cause members of a list to be auto-unsubscribed when their receivers begin to honor p=reject and reject mail integrity DKIM failures. 2) Protocol Awareness, honoring the policy, constraining subscription and submissions to unsecured submissions. Restrictive domains not acceptable for list submissions. Note: It is possible to allow a Read-Only List Member concept. 3) Protocol Awareness, not honoring policy and tearing down the author security, replacing with unsecured distribution. The correct way for any protocol is to close security loopholes. In this case, recommend #2 using Subscription and Submission controls. Let the author domain figure it out. DMARCbis MUST recognize if the intent of the domain is to clean up their brand, by implementing hard failure rejects at both SPF and DMARC, then it should recommend handlers SHOULD honor the policy of the domain or be prepared for the possible false positives. I can understand why DMARCbis's editor does not want to document rewrite, but imto, can't be ignored anymore. The details of a rewrite can be quickly outlined. To help the RFC process, maybe DMARCbis could refer to the Functional Specifications of SSP (RFC5016) Section 5.3, Item 10 which basically reinforces the idea that local policy ALWAYS prevails and it is quite possible there will be undesirable tearing down of secured submissions. One possible mitigation is to replaced it with a secured rewriter with a p=reject policy. I don't think the above will take long to do and I believe will help resolve the conflict. -- Hector Santos, https://santronics.com https://winserver.com ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Receiver-side authorization, was Delegated authentication for Gmail
NOTE: This thread is clearly off-topic with respect to publication. Yet, it may help convergence toward a community vision of the possible future of DMARC, which, in turn, can help finding out a statement about today's limits of DMARC, its interoperability damage, and From: rewriting. On Sat 22/Apr/2023 15:53:40 +0200 Jesse Thompson wrote: On 4/22/2023 6:20 AM, Alessandro Vesely wrote: Those kinds of sender-side authorization schemes seem to be designed for ESP-like businesses, where a domain owner delegates Domain2 to send messages on its behalf. Using such schemes for mailing lists, thereby going down to per-user records sounds improper and bloats the amount of DNS stuff. Does it bloat DNS more than DNSBLs do? Would it make more sense if it were done via HTTPS? The local part of an email address has always been something that can be understood only inside the domain it belongs to. Then, it is true that the pair can be used as a globally unique identifier. However, publishing lists thereof, so as to allow their global interpretation breaks the premise. Here's what I see in the real world: * Organization's policy dictates "use a subdomain" for non-general-purpose use cases. Some organization choose cousin domains instead of subdomains, e.g. yahoo-inc. * Legacy non-general-purpose use of the org domain is tolerated because there is no easy migration path. * People within the organization instinctively want to use the org domain. * They're very confused how it works technically, they try to pull strings to get what they want. * Eventually a person high enough in the organization intervenes. * So, the domain owner has no choice but to authorize the ESP to use the entire org domain, yet again. Sometimes a subdomain is used for functional requirements, such as using different mail servers. Other times it can be categorized as DMARC damage. Why is it improper for a domain owner to have an ability to delegate per-user? I understand that it may be technically infeasible, but why is it improper? I'm still not certain why ESPs are fundamentally different than mailing lists. ESP: A message author confirms their identity with the ESP and asks the ESP to emit mail with their rfc5322.From address MLM: A message author confirms their identity with the MLM and asks the MLM to emit mail with their rfc5322.From address The substantial difference is that every MLM subscriber can post, while ESP communication is one way. In addition, even it both ESPs and MLMs presuppose user's opt-in, verification mechanisms usually differ. To address mailing list and forwarding for address portability, I'd rather devise receiver-side schemes, whereby the final receiver acknowledges that the email address of a user of its has been written to a file that produces mailing list of forwarding effects, while the author domain is not involved at all. A very rough idea here: https://datatracker.ietf.org/doc/draft-vesely-email-agreement/ A scheme like this seems just as applicable to ESPs as it does mailing lists, insofar as mutual consensus of confirmed opt-in can be achieved between all 3 parties. Yes, it is applicable. But ESPs are also characterized by featuring an appointment by the domain owner. Sender-side authorizations, for example publishing the ESP's public key in a purposely created appointer's subdomain, take advantage of that. "Upon user confirmation, that MTA itself confirms the subscription to the MLM." Since you mentioned this enables address portability: If the user changes mailbox providers, how do they communicate all of their prior confirmed subscriptions to the MTA? How does the MLM know if the confirmed subscriptions have not been back-filled? Interesting point. Address portability by forwarding does not actually change the subscription address, so you end up with two agreements. The first is the former domain agreeing to trust a ML where the user subscribed. The second, more critical, agrees to trust MLM messages that the former forwards. These are likely failing DMARC, possibly having a sensible From: domain. In that case, the final receivers could face an ARC chain of two sets, having: Arc-Authentication-Results: i=2; former-isp; dmarc=fail ... That way the former ISP has a permit to send real phishing. The final mailbox provider must really trust the first. Perhaps, the ability to recover a percentage of the author's domain DKIM signatures, albeit not a reliable tool, can play a role in reinforcing that trust. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?
On Fri 21/Apr/2023 18:43:30 +0200 Scott Kitterman wrote: On April 21, 2023 3:57:54 PM UTC, Alessandro Vesely wrote: On Fri 21/Apr/2023 05:41:03 +0200 Scott Kitterman wrote: On April 20, 2023 4:18:08 PM UTC, Dotzero wrote: On Thu, Apr 20, 2023 at 11:38 AM John Levine wrote: It appears that Alessandro Vesely said: IMHO at least an appendix should say that if you can't do anything better you have to rewrite From: with examples of legitimate display-phrase, expanding a bit the first bullet in Section 11.4. That can also be a good place to explain the kind of damage DMARC causes. >>> Absolutely not. This sort of thing is utterly outside the scope of our job and wasting time on it just further delays our already extremely late work. +1 There are many things John and I may disagree on but he clearly understands why avoiding scope creep (and bad ideas) is important. Definitely agree with both of you on this. Eeeh, what an uprising! I just proposed a couple of paragraphs, not a new rocket science theory. As for the badness, why wouldn't a concise but detailed explanation be better than obscure forbiddings and dark forebodings, such as MUST NOT be used by humans or interoperability will break down? BTW, what's the outcome of that discussion? That, specifically is a question for the chairs, so no idea. My recollection is that Barry said a Proposed Standard can get away without MUST NOT. Had we been we aiming at full standard directly before? There are a nearly infinite set of few paragraphs we could write that would make things clearer. If we ever want to finish this, some of them need to be out of scope. Fully agreed. However, I think we must select out of that "nearly infinite set" the paragraphs that explain the MLM issue and other interoperability damage, which includes From: rewriting. Meanwhile, digressions about ATPS and similar schemes can help casting some light on future evolution. From: rewriting cannot be the final solution; it is a temporary hack. Digressions don't slow down the publication, as discussions about actual text quickly prevail. They are just a mean to help convergence toward a common vision of the future. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 23 06:00:04 2023
Count| Bytes | Who ++--- 74 ( 100%) | 827411 ( 100%) | Total 16 (21.6%) | 249185 (30.1%) | Hector Santos 10 (13.5%) | 160009 (19.3%) | Douglas Foster 8 (10.8%) | 49381 ( 6.0%) | Alessandro Vesely 8 (10.8%) | 47318 ( 5.7%) | John Levine 7 ( 9.5%) | 46834 ( 5.7%) | Scott Kitterman 5 ( 6.8%) | 28925 ( 3.5%) | Benny Pedersen 4 ( 5.4%) | 68582 ( 8.3%) | Laura Atkins 4 ( 5.4%) | 52917 ( 6.4%) | Jesse Thompson 4 ( 5.4%) | 48559 ( 5.9%) | Dotzero 4 ( 5.4%) | 45337 ( 5.5%) | Neil Anuskiewicz 2 ( 2.7%) | 10058 ( 1.2%) | Jim Fenton 1 ( 1.4%) | 10325 ( 1.2%) | Murray S. Kucherawy 1 ( 1.4%) | 9981 ( 1.2%) | Mark Alley ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
