On Mon, Feb 14, 2022 at 10:46 AM Todd Herr <todd.herr= [email protected]> wrote:
> 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'" > The heart and core of DMARC policy is about intent. That is, an organization is expressing which messages are authorized are sent on behalf of that organization through the use of either aligned DKIM signing or aligned SPF records. Elizabeth provided more details of the high level examples provided to this group but in a private conversation among parties that are contractually bound, including a confidentiality clause. Among those examples, there were cases of what can only be called misconfigurations (flip flopping of from, mail from, DKIM signing, etc. within the same organizational domain) and other irregularities. > > 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? > > Todd, you are well aware that meeting notes of DMARC.ORG are kept and in fact, those notes have been kept going back well before the date on RFC 7489. Unfortunately, those notes are subject to contractual obligations, including a confidentiality clause, on the part of the participating individuals and the organizations they represent. In fact, there are meeting notes that go back to STAMP, which was the predecessor organization to DMARC.ORG and which created the private implementation of what subsequently became DMARC. Unfortunately STAMP is defunct and I know of no mechanism by which notes and documentation from that group could be made public. Presumably, the participating organizations in DMARC could agree to release any pertinent notes related to alignment from the DMARC.ORG archives. I'll also point out that the authors of RFC7489 were selected at a DMARC.ORG meeting by the participants who all were responsible for the creation and submission of tht RFC. > > 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 made the suggestion that either receivers with access to large data sets, intermediaries or an organization like M3AAWG publicly share to this group (domains obfuscated) sets of examples specifically so that we are not left to depend on hand waving. I may have access to data but it is not my data to share. While I personally believe the security/abuse risks are compelling as to why sibling domains are problematic, I also believe that having the working group see and understand current Sender implementations involving DMARC "sibling domains" and the subsequent operational behavior is important in avoiding similar situations in the future. Michael Hammer
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
