On Sun, Feb 13, 2022 at 5:16 PM Dotzero <[email protected]> wrote: > > > On Sun, Feb 13, 2022 at 4:30 PM Scott Kitterman <[email protected]> > wrote: > > >> >> I think "a" would be cleanest, but I think it would cause too much >> backward >> compatibility trouble and should not be further considered. In previous >> working group discussions on this I recall specific suggestions that this >> would >> be problematic and this is supported by the short survey that Elizabeth >> Zwicky >> reported on. >> > > The problem with what Elizabeth shared, and I do appreciate her sharing > it, is that what she shared doesn't show the extent of the variety of > behaviors in those "sibling" relationships. Because those are undocumented > and not understood AND it isn't even clear that those relationships and > behaviors are what is intended by the "standard", serious questions are > raised. Can a "standard" that allows a variety of undocumented > non-standard behaviors (and outcomes) be considered a standard? The details > behind some of the examples given by Elizabeth indicate potential abuse > vectors beyond my original concerns. Unfortunately, the receiving > organizations most able to provide detailed examples are unlikely to > provide them publicly due to privacy concerns, embarrassing customers, etc. > It might be useful if an organization like M3AAWG could process detailed > examples from members,obfuscate the organizational information and share it > publicly as an aggregation of examples to inform a better standards > creation process. > > > I'm not understanding what you mean when you state that "it isn't even clear that those relationships and behaviors are what is intended by the 'standard'"
RFC 7489 seems to be clear in its definition of alignment. In section 3.1.1 DKIM-Authenticated Identifiers, the text reads, in part: In relaxed mode, the Organizational Domains of both the [DKIM <https://datatracker.ietf.org/doc/html/rfc7489#ref-DKIM>]- authenticated signing domain (taken from the value of the "d=" tag in the signature) and that of the RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From domain must be equal if the identifiers are to be considered aligned. In strict mode, only an exact match between both of the Fully Qualified Domain Names (FQDNs) is considered to produce Identifier Alignment. and in section 3.1.2, SPF-Authenticated Identifiers, the text reads, in part: In relaxed mode, the [SPF <https://datatracker.ietf.org/doc/html/rfc7489#ref-SPF>]-authenticated domain and RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From domain must have the same Organizational Domain. In strict mode, only an exact DNS domain match is considered to produce Identifier Alignment. Both define relaxed alignment as "same Organizational Domain", with no caveats on any other relationship between the two domains being compared. How do we determine intent, especially if the claim is that intent is different from what was written in the RFC? We're fortunate, I guess, that we know how to contact most if not all of the people named in the Acknowledgements section of the RFC, along with the two named authors, but there is literature to suggest that eyewitness testimony is not 100% reliable. Are there notes from the time of writing RFC 7489 to confirm that the intent of the group was to not allow alignment among domains without a direct hierarchical relationship? Whether or not there's evidence regarding intent, that doesn't mean that the case for altering the definition of alignment can't be discussed, but it does determine the argument to be made for the change: - If there's evidence of intent, then the argument is "The definition of alignment needs to change, because the current definition isn't what the authors intended and it exposes domains to security/abuse risks." - If not, then the argument is "The definition of alignment needs to change, because the current definition exposes domains to security/abuse risks." My personal opinion is that arguing this case on just the merits of "The current definition of alignment exposes domains to security/abuse risks, here are examples of how they can be exploited, and here's why those exploits can't be overcome through use of other features of DMARC and/or the underlying protocols" is a pretty powerful argument to make, without worrying about intent, but that's just my opinion. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* [email protected] *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
