Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily
Seth and I discussed this topic today and I think that the central problem that is being debated has to do with *generating* the DMARC report content. Almost everyone agrees that a broken chain is broken and unredeemable - whether that breakage is structural or whether it is because of non-validating signatures. There are three possible levels of processing to be considered: 1. validating a particular individual message for delivery to the recipient - this is easy: a broken chain conveys no useful information for local policy determination 2. feeding ARC information into some larger reputation/ML system in order to provide (what I'll call) a third order policy influence - this one depends on whether the reputation system can make any useful conclusions on the basis of the broken chain. In some cases (where a signature fails to verify) it seems possible, but in many others it seems a bit doubtful 3. generating the DMARC report data pertinent to this individual message - this is where I think that the problem lies. There is a natural desire on the part of senders and report processors to want all the data that they can possibly get; however, it is easy to devise attack scenarios which heavily contaminate the reports if one were to take the content of the entire broken ARC chain into the report My contention to Seth is that in a multi-hop scenario, the *only* report with meaningful data will be the one from the handler who made the "fail" determination and any subsequent reports are untrustworthy. If we are not concerned with "downstream" handlers of a message with a broken ARC chain, then there is no point in attempting to seal the entirety of a failed ARC chain. Do the other folks on this thread agree that our main point of contention has to do with the ability to generate the DMARC report (or the data scoping thereof)? --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Reminder: next ARC interop testing on October 12
We are planning the next in-person ARC interop day on Friday, 2018-10-12 (the Friday following the Brooklyn M3AAWG meeting). For people attending in person, the meeting will be hosted at the Empire State Building. More details are still being finalized, but if you are coming to the M3AAWG meeting, please plan to stay for Friday's interop. You can express your interest (yes, no, maybe) at http://bit.ly/arc -09-interest (thank you to the 12 people who signed up earlier - no need to re-up). --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily
In article you write: >My contention to Seth is that in a multi-hop scenario, the *only* report >with meaningful data will be the one from the handler who made the "fail" >determination and any subsequent reports are untrustworthy. Assuming that "subsequent" means earlier in the chain, I agree. >Do the other folks on this thread agree that our main point of contention >has to do with the ability to generate the DMARC report (or the data >scoping thereof)? Yes. I understand what to do with "here's a valid chain" and "it was broken when I got it", but not "here's a broken chain you may or may not be able to reconstruct." R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily
On Mon, Aug 20, 2018 at 7:18 PM, John Levine wrote: > In article gmail.com> you write: > >My contention to Seth is that in a multi-hop scenario, the *only* report > >with meaningful data will be the one from the handler who made the "fail" > >determination and any subsequent reports are untrustworthy. > > Assuming that "subsequent" means earlier in the chain, I agree. > No, by subsequent I mean intermediaries who handle the message after the point of initial "oh, this is broken" determination. So if I'm the 5th intermediary (let's assume that all are ARC participating for this discussion), and the chain on the message that I receive does not pass the validation checks (for any of the three possible reasons), then my report is meaningful to the sender but reports from 6, 7, 8, etc are not. --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily
(back from vacation and catching up) On Tue, Aug 14, 2018 at 8:58 PM, Seth Blank wrote: > There are THREE consumers of ARC data (forgive me for the names, they're > less specific than I'd like): > > 1) The ARC Validator. When the Validator sees a cv=fail, processing stops, > the chain is dead, and shall never be less dead. What is Sealed is > irrelevant. > Right. 2) The Receiver. An initial design decision inherent in the protocol is > that excess trace information will be collected, as it's unclear what will > actually be useful to receivers. 11.3.3 calls this out in detail. Without > Sealing the entire chain when attaching a cv=fail verdict, none of the > trace information is authenticatable to a receiver (see earlier message in > this thread as to why), which is the exact opposite of the design decision > the entire protocol is built on. To guarantee this trace information can be > authenticated, the Seal that contains cv=fail must include the entire chain > in its scope. This is where this thread started. > I see two possible workflows here: (1) Verifier (to use the DKIM term) detects "cv=fail" and stops, because there's nothing more to do. But the Receiver now has no ARC information except a raw "cv=fail" to relay via A-R or whatever. But this, as you point out, flies in the face of the notion of giving receivers details about the message. The Receiver now has to implement ARC to get whatever details might be prudent from the message. (2) Verifier sees "cv=fail" but will still attempt to verify it and maybe extract other salient details to add to an A-R. When you say "you see cv=fail and stop", I think of the first thing, which is alarming layer mush, and is also ambiguous in that if the Verifier stops dead at seeing "cv=fail", it doesn't matter at all what content got sealed. So if you mean the second thing, part of my issue goes away. 3) The receiver of reports that provide ARC data. For a domain owner to get > a report with ARC information in it, there needs to be some level of trust > in the information reported back. When a Chain passes, all the > intermediaries' header field signatures can be authenticated, and the > mailflow can be cleanly reported back. When a Chain fails, that is > important information to a domain owner (where is my mailflow failing me, > how can I figure this out so I can fix it?). Again, without Sealing over > the entire Chain when a failure is detected, this information is > unauthenticatable (and worse, totally forgeable now without even needing a > valid Chain to replay), and nothing of substance can be reported back. > Sealing the Chain when a cv=fail is determined blocks forgery as a vector > to report bogus information, and allows authenticatable information to be > reported back. > I think we're talking about distinct failure modes. I totally agree with you in the case where the chain has failed because content was altered. But doesn't your assertion here presuppose an at least syntactically intact chain? If the chain is damaged to the point where it cannot be deterministically interpreted, the sealer adding the "cv=fail" might add a seal that a downstream verifier cannot correctly interpret. I understand what you're after but I also understand the intent behind 5.1.2, which is to produce something unambiguous. My problem with 5.1.2 as it stands is that a verifier now has to try verifying the "cv=fail" two ways (one with everything, one with just the last instance), and at least one of them has to work. We've cornered ourselves here by rejecting "cv=invalid". > > And to be even clearer: what is Sealed when cv=fail is reached (itself, > the entire chain, or nothing at all) DOES NOT AFFECT INTEROPERABILITY. But > it does effect preserving trace information and preventing forged data from > being reportable. > I disagree, as stated above; a mangled chain cannot be sealed in a way guaranteed to interoperate. This is my very strong INDIVIDUAL opinion. But I'm fine if the group sees > differently, as this could be investigated as part of the experiment (i.e. > do any of the above points matter in the real world? I say they do, hence > the strong opinion.). As an editor, I'll make sure whatever the consensus > of the group is is reflected in the document. > I've no objection to collecting superfluous trace information to support the experiment. What I'm concerned about is the introduction of weird protocol artifacts or ambiguities that could get baked in and hard to remove later. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily
Hi, I agree with your comments. My input. Keep in mind, that ignorant (non-supportive) ARC nodes will continue to process all DKIM-signature(s) found, such as what I see with your message: Authentication-Results: dkim.winserver.com; dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org; adsp=none author.d=gmail.com signer.d=ietf.org; dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org; adsp=none author.d=gmail.com signer.d=ietf.org; dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=gmail.com header.s=20161025 header.i=gmail.com; adsp=none author.d=gmail.com signer.d=gmail.com; That should be the first consideration and understanding in the pre-ARC DKIM world, i.e. how things are done now. The order of the DKIM-signatures is generaly important here since the typical scenario (with a list) is: 1) Good 1st original Author Domain signature is submitted, 2) 1st signature invalidated at middle ware (LIST), 3) Good 2nd Signature (resign) for LIST distribution 4) MDA see failed original AUTHOR ADSP/DMARC Policy. Overall, the MDA has no explicit 3rd party trust/policy knowledge of LIST or signatures beyond the 1st Author Domain (now broken) signature. That's the basic issue and 12+ years old DKIM Policy model protocol dilemma. I suppose there could be more middle ware, nodes, etc during the transport, but the First and Final processing nodes should be the essential protocol consideration. If there is an cv=fail at #2, does that mean the resigning at #3 is invalidated as well? We never really cared what happens in between during the transport, but with ARC it appears to be a major consideration to better understand transport paths. How ARC will turn all this around, it remains to be be seen. I wish to understand this complex protocol first before justifying the massive overhead and experimentation cost being asked of SMTP/Email developers. Thanks Hector Santos, CTO Santronics Software, Inc. On 8/20/2018 6:28 AM, Murray S. Kucherawy wrote: (back from vacation and catching up) On Tue, Aug 14, 2018 at 8:58 PM, Seth Blank mailto:s...@sethblank.com>> wrote: There are THREE consumers of ARC data (forgive me for the names, they're less specific than I'd like): 1) The ARC Validator. When the Validator sees a cv=fail, processing stops, the chain is dead, and shall never be less dead. What is Sealed is irrelevant. Right. 2) The Receiver. An initial design decision inherent in the protocol is that excess trace information will be collected, as it's unclear what will actually be useful to receivers. 11.3.3 calls this out in detail. Without Sealing the entire chain when attaching a cv=fail verdict, none of the trace information is authenticatable to a receiver (see earlier message in this thread as to why), which is the exact opposite of the design decision the entire protocol is built on. To guarantee this trace information can be authenticated, the Seal that contains cv=fail must include the entire chain in its scope. This is where this thread started. I see two possible workflows here: (1) Verifier (to use the DKIM term) detects "cv=fail" and stops, because there's nothing more to do. But the Receiver now has no ARC information except a raw "cv=fail" to relay via A-R or whatever. But this, as you point out, flies in the face of the notion of giving receivers details about the message. The Receiver now has to implement ARC to get whatever details might be prudent from the message. (2) Verifier sees "cv=fail" but will still attempt to verify it and maybe extract other salient details to add to an A-R. When you say "you see cv=fail and stop", I think of the first thing, which is alarming layer mush, and is also ambiguous in that if the Verifier stops dead at seeing "cv=fail", it doesn't matter at all what content got sealed. So if you mean the second thing, part of my issue goes away. 3) The receiver of reports that provide ARC data. For a domain owner to get a report with ARC information in it, there needs to be some level of trust in the information reported back. When a Chain passes, all the intermediaries' header field signatures can be authenticated, and the mailflow can be cleanly reported back. When a Chain fails, that is important information to a domain owner (where is my mailflow failing me, how can I figure this out so I can fix it?). Again, without Sealing over the entire Chain when a failure is detected, this information is unauthenticatable (and worse, totally forgeable now without even needing a valid Chain to replay), and nothing of substance can be reported back. Sealing the Chain when a cv=fail is determined blocks forgery as a vector to report bogus information, and allows authenticatable information to be reported back. I think we're talking about distinct failure modes. I totally agree with you in the case where
