Subject: [dmarc-ietf] draft-kucherawy-dmarc-base updated (-06)

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 10 Nov 2014 15:52:34 -1000

I've posted an update to the base draft, based on recent feedback from Ned
and others.  Hopefully I've resolved all of the concerns (especially the
major ones), as the ISE would like to send the draft to the IESG for
conflict review in the next day or two.  It also has to begin formal review
of its IANA Considerations section as soon as possible.

Thanks to all who provided recent comments to lead us to this version.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Nov 2014 09:20:12 -0800

On 11/10/2014 5:52 PM, Murray S. Kucherawy wrote:
> I've posted an update to the base draft, based on recent feedback from
> Ned and others. 

Tidbits...

Intro:

>  Security terms used in this document are defined in [SEC-TERMS].

There's a Terminology section, so this really belongs there.

2.2:

> attacks in the RFC5322.From field, also known as "display-name"	
> 			attacks;

     attacks on using the free-form portion of the RFC5322.From field,
also known as "display-name" attacks, after its ABNF rulename;

3.13:

The Flow Diagram inneeds to have the DKIM and SPF boxes /also/ connected
directly to the Filtering Engine, since they still provide information
directly to it.

I suggest either:

    +---------------+
    | Author Domain |< . . . . . . . . . . . . . . . . . . . . . . .
    +---------------+                        .           .         .
        |                                    .           .         .
        V                                    V           V         .
    +-----------+     +--------+       +----------+ +----------+   .
    |   MSA     |<****|  DKIM  |       |   DKIM   | |    SPF   |   .
    |  Service  |     | Signer |       | Verifier | | Verifier |   .
    +-----------+     +--------+       +----------+ +----------+   .
        |                                    *            *        .
        |                                    *        .   *        .
        V                                    **************        .
                                                          *        .
     +------+        (~~~~~~~~~~~~)     +------+          *        .
     | oMTA |------->( other MTAs )---->| rMTA |          *        .
     +------+        (~~~~~~~~~~~~)     +------+          *        .
                                           |              *  .......
                                           | **************  .
                                           V V            *  .
                                     +-----------+        V  V
                       +---------+   |    MDA    |     +----------+
                       |  User   |<--| Filtering |<***>|  DMARC   |
                       | Mailbox |   |  Engine   |     | Verifier |
                       +---------+   +-----------+     +----------+

or

     +---------------+
     | Author Domain |. . . . . . . . . . . . . . . . . . . . . . .
     +---------------+                     .             .        .
         |                                 .             .        .
         V                                 V             V        .
     +------------+     +--------+    +----------+ +----------+   .
     |    MSA     |<****|  DKIM  |    |   DKIM   | |    SPF   |   .
     |  Service   |     | Signer |    | Verifier | | Verifier |   .
     +------------+     +--------+    +----------+ +----------+   .
         |                                    *       *           V
         |                                    *       *     +----------+
         |                                    *************>|  DMARC   |
         |                                            *     | Verifier |
         |                                            *     +----------+
         |                                            *        *
         |                                            * ********
         |                                            * *
         |                                            V V
         V                                      +-----------+
      +------+    (~~~~~~~~~~~~)    +------+    |   MDA     |
      | sMTA |--->( other MTAs )--->| rMTA |--->| Filtering |
      +------+    (~~~~~~~~~~~~)    +------+    |  Engine   |
                                                +-----------+
                                  +---------+        |
                                  |  User   |<-------+
                                  | Mailbox |
                                  +---------+

Since Murray saw a variant of the latter from me earlier, he won't be
surprised that I prefer it...

5. Policy:

>    A Domain Owner may choose not to participate in DMARC evaluation by

   may -> can

(I'm assume that we don't use normative language to tell people that the
have the right to opt out of a specification...  Hmmm.  Normative
language would actually be contradictory, I think...)

>    Mail Receivers.  In this case, the Domain Owner simply declines to
>    advertise participation in those schemes.  For example, if the
>    results of path authorization checks ought not be considered as part
>    of the overall DMARC result for a given Author Domain, then the
>    Domain Owner does not publish an SPF policy record that can produce
>    an SPF pass result.

The way to opt out of DMARC is to not publish a DMARC record.  So "those
schemes" doesn't make sense to me, nor does the reference to an SPF record.

I think this should say:

     Mail Receivers.  In this case, the Domain Owner simply declines to
     advertise participation.  That is, the Domain Owner does not
     publish a DMARC record in the DNS.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 13 Nov 2014 00:26:53 +0100

Hi, Murray,

On 11/11/2014 02:52 AM, Murray S. Kucherawy wrote:
> Ned and others.  Hopefully I've resolved all of the concerns 
> (especially the major ones), as the ISE would like to send the draft 
> to the IESG for conflict review in the next day or two.  It also has 
> to begin formal review of its IANA Considerations section as soon as 
> possible.
>

I started earlier this week a review of -05. Please find below my 
comments, I think most if not all of them also apply to -06. I didn't 
have time to finish my review, but thought to send my comments 'as is' 
(before -07 is published ;-)). Most of my comments are of type 
'editorial nits', no big changes proposed ;-)

Regards,
/rolf

Abstract:

    This lack of cohesion has several effects: receivers have difficulty
    providing feedback to senders about authentication, senders
    therefore have difficulty evaluating their authentication
    deployments, and as a result neither is able to make effective use
    of existing authentication technology.

This focuses on the reporting function of DMARC, leaving out the policy 
part of it.

Suggested text:

    This lack of cohesion has several effects: senders have difficulty
    providing information about their use of an authentication policy
    and receivers have difficulty determining a disposition preferred by
    senders. Vice versa, mail receivers have difficulty providing
    feedback to senders about authentication, senders therefore have
    difficulty evaluating their authentication deployments, and as a
    result neither is able to make effective use of existing
    authentication technology.

Introduction:

    [...] mail receivers have tried to protect senders [...]

Suggested:

    [...] mail receivers have tried to protect senders and their own
    users/customers [...]

Starting with "DMARC allows domain owners and receivers to collaborate 
by", the terms 'domain owners', 'receivers', 'senders' and 'SMTP 
receivers', 'Mail Receivers', 'mail receivers' are used throughout the 
document. I'd suggest to add a definition of the term ' Mail Senders' to 
the introduction part of chapter 3 and then use only the terms as 
defined in 3., throughout the document. Suggested text for the term Mail 
Sender:

  * Mail Sender: the sender of mail with a domain for which the Domain
    Owner may have published a DKIM public key and/or an SPF
    authentication record and/or a DMARC policy;

(although we may want to not mention DKIM or SPF here).

2.2 Out of Scope

Add:

o    cousin domain attacks

3.1.2 Key Concepts

Last sentence: add a reference to this 'other referenced material'.

3.1.3 Flow diagram

The box titled 'User Mailbox' could give the impression that there's 
only one choice for delivery. However, quarantining can be done without 
delivery to a mailbox. I'd suggest to label this box 'rMDA'.

The part within parentheses of step 6:

>  6. Recipient transport service conducts SPF and DKIM authentication 
> checks by passing the necessary data to their respective modules, each 
> of which require queries to the Author Domain’s DNS data (when 
> identifiers are aligned; see below).

might indicate that SPF and DKIM authentication checks need not be 
performed when identifiers are not aligned. However, for sake of 
reporting, SPF and DKIM authentication checks will in general always be 
done, or am I missing something?

3.1.4.1 DKIM-authenticated Identifiers

remove (or change) the 'Cousin Domain' example: it doesn't hold when a 
bad actor is signing the mail with d=cousindomain and 
RFC5322.From=localpart@cousindomain

4 Use of RFC5322.From

Last bullet (The DMARC mechanism ...). It seems the other bullets 
provide reasons why RFC5322.From is chosen while the last one does not. 
It looks to me as a circular reasoning.

5.2 DMARC URIs

It is not clear from the text what the report originator must do when 
the report payload exceeds the maximum size as indicated by the record. 
Should it not send anything, should it split up reports, should it 
notify the requester that there was a report exceeding the maximum size?

5.3 General Record Format

adkim and aspf do not provide a list of all possible options (like is 
done for fo and p). Of course it is pretty obvious that for 'strict' the 
's' must be used, but it's not clear from the text.

Suggested edit:

    adkim: (plain-text; OPTIONAL, default is "r".) Indicates whether
    strict or relaxed DKIM identifier alignment mode is required by the
    Domain Owner.

    Possible values:

    r: relaxed DKIM identifier alignment mode required
    s: strict DKIM identifier alignment mode required

    See Section 3.1.4.1 for details.

and

    aspf: (plain-text; OPTIONAL, default is "r".) Indicates whether
    strict or relaxed SPF identifier alignment mode is required by the
    Domain Owner.

    Possible values:

    r: relaxed SPF identifier alignment mode required
    s: strict SPF identifier alignment mode required

    See Section 3.1.4.2 for details

Next, the P: and pct: tags: they show that (in hindsight) the policy 
part and the reporting part of DMARC might have been better off, when 
they were defined in different specs. Now we need to complicate the text 
to say that the policy tag p: is required, but not for third-party 
reporting records. And for pct, that it "MUST NOT be applied to the 
DMARC-generated reports". Well, I believe this has been discussed 
before, no need to redo this discussion.

I'd suggest to synchronize the short description of the tags in 5.3 with 
the descriptions of the tags in the table of 10.4 (now different 
terminology is used here and there, for example Requested Mail Receiver 
policy (5.3) and Requested handling policy (10.4). Suggested text in 5.3 
becomes then:

    adkim: DKIM alignment mode (plain-text; OPTIONAL, default is "r".)
    Indicates whether [...]

    aspf: SPF alignment mode (plain-text; OPTIONAL, default is "r".)
    Indicates whether [...]

    fo: (leave as it is)

    p: Requested Mail Receiver Policy (plain-text; REQUIRED for policy
    records). Indicates [...]

    pct: Sampling rate (plain-text integer between 0 and 100, inclusive;
    OPTIONAL; default is 100). Percentage of messages [...]

    rf: Failure Reporting Format(s) (colon-separated plain-text list of
    values; OPTIONAL; default "afrf"). Format to be used for
    message-specific failure reports. [...]

    ri: Aggregate Reporting Interval (plain-text, 32-bit unsigned
    integer; OPTIONAL; default 86400). Indicates [...]

    rua: Reporting URI(s) for aggregate data (comma-separated plain-text
    list of DMARC URIs; OPTIONAL). Addresses to which aggregate feedback
    is to be sent. A comma or exclamation point [...]

    ruf: Reporting URI(s) for failure data (comma-separated plain-text
    list of DMARC URIs; OPTIONAL). Addresses to which message-specific
    failure information is to be reported. If present [...]

    sp: Requested Mail Receiver Policy for subdomains (plain-text;
    OPTIONAL). Indicates [...]

    v: Specification Version (plain-text; REQUIRED). Identifies [...]

and then change the corresponding table in 10.4 as follows:

    for p: use 'Requested Mail Receiver policy'
    for sp: use 'Requested Mail Receiver policy'.

Further suggestion for the table in 10.4: reverse the order of 'p' and 
'pct' as 'p' is first discussed in the text of 5.3, before 'pct'.

Suggestion for 'ri': remove the normative language (MUST and SHOULD) as 
that might ask for a 'compliancy'  section. Instead, move these 
suggested values to the BCP document.

5.6.2. Determine Handling Policy

Bullet 6 in combination with the introduction text might give the 
impression that the receiver MUST always follow the policy as published 
by the Domain Owner. Suggestion to replace the text:

    6. Apply policy. Emails that fail the DMARC mechanism check are
    disposed of in accordance with the discovered DMARC policy of the
    Domain Owner. See Section 5.3

with:

    6. Apply policy. Emails that fail the DMARC mechanism SHOULD be
    disposed of in accordance with the discovered DMARC policy of the
    Domain Owner. See Section 5.3

5.6.3. Policy Discovery.

This paragraph states that:

    If the RFC5322.From domain does not exist in the DNS, Mail Receivers
    SHOULD direct the receiving SMTP server to reject the message. The
    choice of mechanism for such rejection and the implications of those
    choices are discussed in Section 9.3.

Although this might be common practice (either by default MTA settings, 
or by configuration parameters set by many mail operators), I believe 
this informational RFC about DMARC cannot use normative language here to 
decribe what must be done with mail with a domain that is not present in 
DNS.

5.7 Last sentence:

    Mail Receivers SHOULD also implement reporting instructions of DMARC
    in place of any extensions to SPF or DKIM that might enable such
    reporting.

Not sure what this means. But it seems to me DMARC cannot claim priority 
over other options/extensions in other IETF protocols.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 12 Nov 2014 13:37:02 -1000

>  Hi, Murray,

Hello Rolf,

> comments, I think most if not all of them also apply to -06. I didn't have
> time to finish my review, but thought to send my comments 'as is' (before
> -07 is published ;-)). Most of my comments are of type 'editorial nits', no
> big changes proposed ;-)
>

Thanks for taking time to take a closer look.  At this point I'm not going
to be making any other changes unless they are attempts to resolve things
that are either major errors (i.e., they don't reflect the deployed DMARC
base or are plainly wrong) or would cause the IESG's conflict review to
return a blocking concern.

If it does come back from the IESG for more editing, I'll take a run at
applying your suggestions.

Thanks again,

-MSK