I mean in the AR arc=result header.b=... header.b=... And then this gets captured in the AAR when a message is signed.
Seth On Tue, May 30, 2017 at 4:43 PM, Brandon Long <[email protected]> wrote: > I'm not clear, are you saying requiring the header.b for every dkim > resinfo in the AAR, or requiring it for the arc=result resinfo? > > It has always seemed odd to me that the spf one didn't include the IP as > well, since it's certainly input, I guess I should go archive spelunking > again. > > Brandon > > On Tue, May 30, 2017 at 2:14 PM, Scott Kitterman <[email protected]> > wrote: > >> On Tuesday, May 30, 2017 01:34:50 PM Seth Blank wrote: >> > On Tue, May 30, 2017 at 11:43 AM, Scott Kitterman <[email protected] >> > >> > >> > wrote: >> > > On Tuesday, May 30, 2017 10:14:08 AM Seth Blank wrote: >> > > > The current spec defines an arc authres method ( >> > > >> > > https://tools.ietf.org/html/ >> > > >> > > > draft-ietf-dmarc-arc-protocol-03#section-8.1). >> > > > >> > > > We believe there should also be registered ptypes and properties, >> that >> > > > should be stamped (but are not required, as they won't always be >> > > >> > > available). >> > > >> > > > As long as AR stamping happens at the end of chain validation, when >> an >> > > >> > > ARC >> > > >> > > > set gets created this stamp will be included in the AAR, and AAR >> > > > construction can be clean with no additional language or >> requirements >> > > > necessary in the spec. >> > > > >> > > > What follows below is not sacred, we're just trying to start the >> > > > conversation. >> > > > >> > > > Based upon previous threads (specifically, Brandon's reporting >> > > >> > > local_policy >> > > >> > > > thread from May 4th PST) surrounding the AAR and data the WG thought >> > > >> > > would >> > > >> > > > be valuable for final receivers and DMARC reports, it looks like >> > > > stamping >> > > > header.b for each dkim signature on the message and smtp.client-id >> for >> > > >> > > the >> > > >> > > > ip address of the originating mail server (if available) would >> provide >> > > > nearly everything asked for with minimal implementation overhead >> (and no >> > > > change to spec except for the IANA registration, and an addition for >> > > > RECOMMENDED stamping if warranted). >> > > > >> > > > To dig in to the reasoning behind these two properties: >> > > > >> > > > 1) header.b >> > > > >> > > > At the end of an ARC chain, there might be many DKIM signatures on >> the >> > > > message, nearly all of which could be broken on receipt. >> Additionally, >> > > > since there have been multiple hops, it is possible to have several >> > > >> > > broken >> > > >> > > > DKIM signatures with the same header.d value that are >> representative of >> > > > different services at different hops. >> > > > >> > > > If each hop stamps the https://tools.ietf.org/html/rfc6008 >> header.b of >> > > > every dkim key on the message, then it becomes super clear which >> keys >> > > >> > > were >> > > >> > > > added when, and which dkim pass/fail statuses correspond to which >> keys >> > > > so >> > > > it can be determined when any individual signature broke. >> > > > >> > > > This is extremely useful as a reporter to help identify broken >> services >> > > >> > > at >> > > >> > > > any stage of DMARC enforcement, and is probably useful for final >> > > >> > > receivers >> > > >> > > > reviewing the chain to determine final message disposition; without >> this >> > > > information all the DKIM-Signatures on a message that do not >> validate >> > > > and >> > > > share the same header.d are indistinguishable. >> > > > >> > > > This stamp removes this ambiguity and adds reporting and trace >> value. >> > > > >> > > > >> > > > 2) smtp.client-id >> > > > >> > > > The goal here is to track the originating source_ip for DMARC >> > > > categorization and reporting. Otherwise, all ARC messages will have >> a >> > > >> > > DMARC >> > > >> > > > report source_ip of the last forwarder, not the originating service. >> > > > This >> > > > will be exceptionally confusing to consumers of DMARC reports. >> > > > >> > > > We know that including an IP address in Authentication-Results has >> been >> > > > persona-non-grata in the past, as authentication results are >> supposed to >> > > > encapsulate the results of an authentication check, not information >> that >> > > > could be used to re-run the authentication downstream. >> > > > >> > > > However, we believe that the client-id is vital trace information >> for >> > > > ARC >> > > > and DMARC, is useful for categorizing senders within a DMARC >> report, and >> > > >> > > is >> > > >> > > > valuable at p=none, p=quarantine, and p=reject, and as such makes >> sense >> > > > within and contained to the ARC stamp. >> > > > >> > > > Ultimately, if this stamp is wrong for the AR, the client-id could >> be >> > > >> > > added >> > > >> > > > directly in the AAR. The AR stamp is cleaner because it leaves the >> AAR >> > > > generation and spec untouched. >> > > > >> > > > >> > > > We know there will be disagreement about what to stamp, and welcome >> > > > discussion on what's best to track within an AR header as arc >> status. >> > > > >> > > > I'm happy to suggest language once there's rough consensus in the >> group. >> > > >> > > When msk initially defined the Authentication Results header field, I >> was >> > > a >> > > strong proponent of including trace elements, but was in the rough as >> it >> > > comes >> > > to the consensus. In retrospect, I think he was correct. >> > > >> > > AAR can't truly be a trace header (you'd have to include the entire >> > > unmodified >> > > message with the original DKIM signature to make the DMARC inputs >> > > traceable). >> > > I'm not sure it's worth doing it half-way. >> > >> > I don't want the AR payload to be about trace information; I want to >> make >> > sure it encapsulates the proper authentication results and statuses. So >> > that a DMARC report after an ARC message has been processed has the >> > appropriate information that's valuable to a report consumer. >> > >> > - At p=none this means understanding the originating sender and if any >> > originating authentication mechanisms were broken. This means passing >> > through an smtp.client_id and the header.b's. >> > >> > - At p=quarantine|reject, for a failing message that passes arc, I think >> > the status quo works (although having header.b here to understand which >> > keys signed the message when could be useful). >> > >> > - At p=quarantine|reject, for a failing message that fails arc, it's >> useful >> > to know where/why the message failed. Again, header.b's shine light on >> this >> > and can make the DMARC report useful for determining/fixing a broken >> > originating sender or intermediary. >> > >> > Passing this information through (and to me it's not trace if it's there >> > for a user to interact with in a DMARC report - although there's >> definitely >> > additional trace value, that's not the primary purpose here) is >> extremely >> > valuable for the report consumer. >> > >> > My concern is putting it anywhere other than the AR/AAR could creative >> > feature/spec creep, and waiting to see what happens and writing a spec >> for >> > stamping later just leaves room open for complaints that, even after >> ARC, >> > DMARC is still broken with respect to reporting on mailing list and >> > forwarders. >> > >> > > I'm particularly not convinced about source_ip. DMARC reports are >> > > organized >> > > by 5322.From and when I'm reviewing reports what I care about is >> where the >> > > reporting receiver got it from. That's already covered. >> > >> > I'm not certain I'm sold either. Especially because many implementations >> > won't even have access to the IP. For instance, Mailman3 does not have >> > access to the source_ip of the smtp connection (that data doesn't come >> over >> > LMTP), so no mailman software would ever be able to stamp this. >> > >> > I think the source_ip is valuable to provide, especially for a final >> > consumer of a report, but 1) it's not always available, 2) it doesn't >> seem >> > perfect to put into an AR header. >> > >> > Thoughts? >> > >> > > I don't see anything that might support trace uses that has to be in >> the >> > > initial specification. It can be added later if there's a need. >> > >> > I think stamping header.b has real value as outlined above. >> > >> > I think smtp.client_id also has value, but definitely see the arguments >> > from both sides. >> >> So header.b only gives an explicit way to link an (A)AR header field with >> a >> signature, so there's no need to guess what's related within the >> message. Now >> that I've read your rationale and gone and read RFC 6008 again, I agree >> that >> makes sense to include in AAR. It might even be a good idea to make it >> mandatory since there is (for the purposes of IETF standardization) no >> installed base to worry about. >> >> Source IP, I still this is only for trace purposes and should be out of >> scope >> (I have a hard time justifying why it would be out of scope for SPF >> (which is >> what the working group and later IETF consensus was) and in scope here. >> >> Scott K >> >> _______________________________________________ >> dmarc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmarc >> > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc > > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols [email protected] +1-415-894-2724 <415-894-2724>
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
