On 7/9/18 7:28 PM, Kurt Andersen (b) wrote:
On Mon, Jul 9, 2018 at 3:01 PM, Jim Fenton <[email protected]
<mailto:[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?
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.
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.
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.
- AMS says that it's basically a DKIM-Signature header field with
an instance tag and no version. Why not just add an optional
instance tag to DKIM-Signature? But I do see a semantic difference
that isn't listed in 4.1.2. The order of inclusion of "instanced"
header fields is based on the instance number, not simply
bottom-up as in DKIM. I can see why this is done, since header
field ordering isn't guaranteed to be preserved. But I haven't
found anything that fully orders the header fields in this case;
do the "instanced" header fields go before the others, after the
others, or some other way? Note that even if distinct header field
names are used, the h= value in the DKIM-Signature specifies
what's included, not the order.
The ordering is clearly defined - when "h=" cites (using abbreviated
header names) "DKIM:DKIM:Date:AAR:AMS:AAR:AMS:AAR:AMS" that would be
AAR[1]:AMS[1]:AAR[2]:AMS[2]" per the definition.
OK; my recollection of how the DKIM h= tag/value works was incorrect. So
the first DKIM picks up the bottommost signature and the second one
picks up the second from the bottom, but the selection of AAR and AMS is
based on instance number, not position. That's not ambiguous, but it
would be good to point the header field ordering out as an additional
(fourth) difference between AMS and DKIM-Signature in 4.1.2.
- 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.
In the ABNF for the AMS header field (and others), where is
"instance" defined?
instance is defined in section 3.6
Thanks; don't know how I missed it. It uses i=, which is already a DKIM
tag. In describing the differences between AMS and DKIM-Signature, 4.1.2
should prohibit the DKIM use of i= in AMS. Or it should use a different
tag letter.
"Authentication-Results header fields MUST NOT be included in AMS
signatures": This seems harsh, especially since Section 5 of
7601bis (cited, also RFC 7601) make inclusion of
Authentication-Results a MAY. Is there a reason for the much more
restrictive wording here?
Yes, and it goes back to the "ephemerality" of A-R headers. We want to
avoid signing any content which downstream handlers can arbitrarily
delete.
OK; see above comment re 7601.
4.2.1: Instance tag value range: Why 50? That seems like an
arbitrary choice; is there some other basis for it?
The choice of 50 is somewhat arbitrary, in that it could equally well
be 49 or 75. Early versions specified values up to 1024 would be
legal, but since the working group felt that handling chains over 10
ADMDs to be fairly unlikely, we thought that a 5x margin should be
sufficient without allowing completely ridiculous header bloat.
Makes sense. Maybe include something informational to that effect?
Informational paragraph: Since the cited DCRUP work has passed
IESG approval (just got a state update to "Waiting on RFC Editor"
as I type this), it sounds like the ARC-MULTI stuff ought to be
here rather than in a separate document. But there are other
reasons for having multiple DKIM-Signatures on a message, such as
key rotation. ARC needs to be able to deal with this; perhaps it's
all covered in ARC-MULTI which I haven't read yet.
Yes, it's the ARC-MULTI doc. We split them so that we can get the
basic protocol through WGLC before wrestling through multiple
algorithms and algorithm migration.
I disagree with the split. I don't think this spec is complete without
guidance on how to handle multiply-signed messages, which will become
sharply more prevalent with the DCRUP work.
5.1.1: As noted above, needs to completely specify the order in
which header fields are supplied to the hash function (both ARC
and non-ARC header fields).
Will review the text to clarify.
5.2 step 5 et seq: Are some of the following steps sub-steps to 5
(done repeatedly for each ARC set)? There's a colon there but not
sure how far it goes.
The colon is a typo, should be a period.
Please double-check this; step 6 at least reads like it's something done
iteratively as introduced in step 5.
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?
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.
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.
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.
Appendix B: It would be really, really helpful to have at least
one example here.
Yes, planning to...up until version -13, we had carried some very old
examples which were now causing more confusion as people looked at the
examples rather than the text.
Making sure that the example(s) is/are correct is an important thing to
have reviewed carefully. This would be great to have before Last Call.
-Jim
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
