On Tue, Jul 10, 2018 at 12:13 PM, Jim Fenton <[email protected]> wrote:
> On 7/9/18 7:28 PM, Kurt Andersen (b) wrote: > > On Mon, Jul 9, 2018 at 3:01 PM, Jim Fenton <[email protected]> > wrote: > >> Substantive issues: >> >> General: I see lots of references to "authentication state", beginning >> with two references in the abstract, but I don't see the term defined >> anywhere. Perhaps add to the general concepts (section 2). >> > > While I understand your question, is the combination of the two terms not > self-evident? Is it something that needs to be further expanded upon? If > so, can you suggest some language which might have satisfied your > uncertainty? > > > I wasn't clear on what all is included in authentication state. Is it just > the question of whether the message currently passes an authentication > check, or whether authentication is asserted by a third party through an > ARC seal? > Since this is a general question, a general reply: What ARC seeks to do is capture what the sealer saw in terms of authentication results at the time it handled the message, and attach those results to the message in a way that they cannot later be falsified. That collection of results coupled with the identity of the sealer is what I think is meant by "authentication state". While I think of it, I'm wondering if ARC covers message authentication via > SPF or DKIM only. Presumably only the first hop from the originating ADMD > would pass SPF, and then DKIM is used after that? It might be good to > mention relationship with non-DKIM authentication somewhere. > I think ARC is agnostic about particular methods. It just records all of that state and passes it forward. It's up to the receiver (mainly a DMARC processor) to decide what to do with it. > > >> 4. Protocol elements: It's not immediately evident to me why we need new >> header fields here rather than extensions to existing header fields: >> >> - AAR is basically an Authentication-Results with an added instance tag; >> why not just do that? >> > > Because A-R is ephemeral and, per 7601 both can and should be deleted at > will. > > > I'm fine with deleting clearly fraudulent A-R (spoofed A-R claiming to be > from the receiving MTA's own ADMD). But IMO it's really unfortunate that > 7601 is so free about (and even encourages) deleting A-R header fields, > because in this case it means that they need to be, essentially, duplicated > for ARC, with the message header bloat that entails. > RFC7601 doesn't require or encourage deletion of A-R fields in general. (The strongest word is "could".) If it's valid and possibly useful downstream, you can certainly keep it. It only says you have to delete stuff that's clearly a forgery. > Is it possible for this spec to update 7601 by saying something like, > "MTAs implementing ARC MUST NOT delete A-R header fields containing > instance tags"? I need to think more about message paths containing a > mixture of ARC-aware and ARC-unaware MTAs and whether there are any issues > there, and would need to consider this as well. > It could. > > > > - AS: I'm having trouble understanding what this is for. Why do we need >> another layer of signature on top of that in the AMS? >> > > Because the AS, signing only the ARC chain headers, provides a less > fragile/more resilient mechanism for chain continuity. By scoping to just > the ARC chain, we expect less collateral breakage than any signature which > covers arbitrary headers and body. > > > The point of signing the body in DKIM was to make sure that there was no > opportunity to splice a different body onto a validly signed message. This > was considered important when we discussed the l= (length) tag/value on > DKIM signatures, because there was concern that an attacker could append > content to a message with a valid signature. > > My concern with this is that since AS isn't signing the body but is being > depended upon for message handling decisions, this might be exploited by an > attacker. This needs, at a minimum, to be a security consideration. > AMS is basically the same as DKIM-Signature, and so it covers body modifications. When you verify the seal, you must also verify the latest AMS, which in turn means the seal is invalidated as soon as someone changes the content. > > > 5.2.2 conflicts with the second to last paragraph in 5.2 that a message >> with a failing ARC MUST be treated the same as one with no ARC. >> > > Not really, but the process is not clearly spelled out. If an incoming > message fails to have a passing DMARC result and the ARC chain does not > provide sufficient information (or trusted information) to mitigate a > resulting "REJECT" policy, then a message can be REJECTed during the SMTP > transaction with this extended result. No ARC chain would have the same > result as a failing one in such a case. > > > 5.2.2 refers to an ARC validation failure, not a DMARC policy action. If a > rejection occurs, it's DMARC that is doing that, not ARC. Perhaps there > will need to be an update to DMARC to describe how it processes ARC results? > I agree that this needs to be said somewhere. One of the work items of this WG is a standards track update to DMARC, so it could be punted to there as well. > >> 9.1 is not a security consideration, or at least it's not in expressed in >> terms of how an attacker might exploit ARC to cause problems with header >> size. >> > > I agree that this is not really a security issue - but it is a potential > operational one. Where should this caution be moved do? > > > I'm not sure there is a defined place. Perhaps an informational note in > 4.3 where it's describing the chain as a whole would be an appropriate > place for this. > I disagree. If I can cause your MTA to crash because of oversized header fields, that's at least a denial of service attack. If I can cause your filter to crash because of oversized header fields and your MTA fails open, I can bypass whatever protections the filter offers. > > >> 10. I don't see any other reference to header.s so I'm not sure what the >> bracketed comment at the beginning is referring to. >> >> 10.2 I'm not clear on why there is an IANA consideration for the "s" >> signature tag (perhaps this is the header.s above). >> > > Yes, the "s" tag is the "header.s" ptype when more fully specified. I'll > clarify the note to the editor. > > The formatting in there is broken. It'll be easier to see what's going on when that gets fixed. But still, something needs to register "header.s". If these two documents go to the editor together, we'll jsut have to pick one to contain the registration and remove it from the other one. > >> 13.2 Not clear to me why previous revisions of this draft are included as >> informative references. ARC-MULTI (IMO) should be included in this draft. >> ENHANCED-STATUS looks like a normative reference to me. Some of the >> references to 7601bis might also be normative; can these be changed to 7601 >> (non-bis)? >> > > The previous versions are cited because some of the implementations listed > in section 12 were built to earlier versions and have not necessarily been > vetted against the current version. With the removal of section 12 upon > publication, those earlier versions can also be dropped. > > The references to 7601bis will be normative, but only once the updated > document number is issued. I don't think that we can cite a "bis" as a > normative reference. > > > At publication, you shouldn't cite an Internet Draft at all since it will > expire. Whether references are normative or informative doesn't depend on > the status of the document, but on the nature of the reference. I'm under > the impression that this document is ahead of 7601bis for publication. If > it depends on things that are new in 7601bis, then it will need to wait for > 7601bis to be published. Otherwise, suggest you make the references to 7601 > instead. > I disagree. I've had RFCs published that reference in-progress drafts, in one case one that never got published. But in this case, they would just hold this until 7601bis was also ready, and publish them as a cluster. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
