On Monday, February 14, 2022 10:45:39 AM EST Todd Herr wrote: > On Sun, Feb 13, 2022 at 5:16 PM Dotzero <dotz...@gmail.com> wrote: > > On Sun, Feb 13, 2022 at 4:30 PM Scott Kitterman <skl...@kitterman.com> > > > > 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.
I agree, but generic arm waving is not useful. We need specifics to understand the concern. I have a suspicion that it will amount to a third-party delegation concern that is best addressed by explaining potential risks and mitigations in security or privacy considerations, but without knowing anything about what the actual issue is there is no way to know. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
