So, history, the concepts of ARC come from the XOAR as implemented by Google.
There, there is the XOAR header and it's covered by the X-Google-DKIM-Signature header. This translated to the AAR covered by AMS. ARC obviously has the second layer with the AS, which seems likely to provide the same level of protection. I don't really see the implementation challenge with requiring this, but I'm open to removal if there is no utility to it. I'm trying to think through scenarios to see if there's anything stronger that this gives us, but I haven't seen any yet. AMS covering AAR means that you could "trust" the AAR even if the chain itself is compromised, but we've typically said "a broken chain should be ignored", and I think that statement should still hold. There is the oddness that the AS and AMR don't have any requirements to be the same. With AAR not covered by AMS, you could replace the AAR/AS for a hop, and sign the AS with a different key. That means the AAR's trust vector is just the AS and not both (AS/AMS). Brandon On Tue, May 30, 2017 at 3:11 PM, Gene Shuman <g...@valimail.com> wrote: > The two list approach to configuration actually seems sensible in general, > I'll discuss this with msk. > > However, if the recommended AAR inclusion language accomplishes nothing, > shouldn't we remove it, regardless? > > On Tue, May 30, 2017 at 3:00 PM, Brandon Long <bl...@google.com> wrote: > >> >> >> On Tue, May 30, 2017 at 1:35 PM, Gene Shuman <g...@valimail.com> wrote: >> >>> So I'm actively doing development on OpenARC right now, and this >>> definitely something that is being a source of some non-trivial >>> awkwardness. >>> >>> Can anybody recall why the aforementioned language of recommending >>> including the AAR's in the AMS is in there? Afaik, it seems to make no >>> sense, and is causing some implementation specific awkwardness wrt both >>> OpenARC & the test suite. >>> >>> So one would expect that for an ARC implementation, we would want a >>> simple configuration option that tells us which headers to sign. I believe >>> OpenDKIM behaves in exactly this fashion. And it needs to be able to >>> include duplicates, as that's a require feature of the rfc. But this >>> recommendation to include AAR's in the list makes this awkward, as, as we >>> can't configure this in a similar fashion, as we dont know how many AAR's >>> are in messages a prior. >>> >> >> I think this is broken. Why would you ever configure "only sign two >> copies of this header, but not three"? I'd expect two lists, one of which >> headers to sign, and one of which headers to add as empty to prevent extra >> copies of the header to be added. Ie, in dkimpy, that's the SHOULD and >> FROZEN lists. >> >> >>> So either an implementation will either need some AAR inclusion >>> configuration option, independent of the other h= configuration list, or it >>> needs to make some internal decision of whether to be signing these headers >>> or not. The first option is awkward & seems just kind of needlessly >>> complex. And I'm also not a fan of implementations making this kind of >>> decision internally, as I think its important from a testing standpoint to >>> have the output headers be predictable. >>> >>> So can anybody recall why this language is there? It seems kind of >>> pointless in the best case, and slightly harmful in the worst. Unless >>> somebody has a reason for it being there, I suggest we remove it. Or why >>> not just actively forbid the inclusion of all ARC-Set header fields in the >>> AMS while we're at it? That seems like a plausible idea. >>> >> >> The AMS was arrived at incrementally, as was the AAR (originally there >> was just one AAR, not a full chain). I guess it's not required, though I'm >> not sure about the harmful part. >> >> Brandon >> > >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
