This got caught in list moderation and I accidentally disc= arded it.=A0 However it was also sent direct to me, so I do still have it; = re-sending.

---------- Forwarde= d message ----------
From: Eliot Lear <lear@cisco.com>
Date: Tue,= May 21, 2013 at 3:09 AM
Subject: Eliot's review of the DMARC spec To: dmarc@ietf.org, draft-kucherawy-dmarc-base.= all@tools.ietf.org, Barry Leiba <barryleiba@computer.org>

=20 =20 =20

I've been asked to take a look at the DMARC spec.=A0 Let me start b= y saying that I know that you guys have running code.=A0 I beg your indulgence and ask you to read through.=A0 While this review may come across as a bit negative, and while I have concerns about several components (potential downgrade attack etc).

In general I'd say this document needs some cleanup, and in my opinion, it is not ready to move forward as a proposed standard.=A0 To start with, the requirements section is horribly confused.=A0 Some are not requirements but specifications, others are vague.=A0 They read like there was a negotiation among the contributors on what to keep out and what to keep in, or perhaps these are markers for the working group.=A0 Whatever.=A0

The whole section needs to be replaced with something simpler, like:
[1]=A0 Here is what the specification is out to accomplish (and not accomplish).
[1a] A formal description of the threat model
[2]=A0 Here are the assumptions we make about sender capabilities
[3]=A0 Here are the assumptions we're making about receiver capabilities.

Let me stress conciseness!!

The document is laden with terms that are either explained later or not explained at all (see below for examples).

A clear overview of the entire system should be provided.=A0 It needn't be long; perhaps a page or two.=A0 Yes, include a pretty AS= CII picture (maybe a swimming pool diagram or two).

Please also intersperse the examples.=A0 Otherwise the reader has to jump all over the document.

The Security Considerations section needs a serious edit cut.

More detailed comments below.=A0 This list is incomplete and should receive further review, once the document is updated.

Sections 2.1 =96 2.3 are advertisements for the mechanism, and largely vacuous.=A0 I would be happy to read how DMARC actually helps with phishing or scaling, but these sections don't go into enough detail to be meaningful.=A0 Particularly off putting is the statement:

=A0=A0 [...] the DMARC mechanism is viewed mo= re importantly as a
=A0=A0 substantial step forward in terms of creating reliable and defensible
=A0=A0 message streams.

By whom and why is it more important?=A0 Let's avoid the advertisements and the appeal to some vague authority.

Section 3 needs a fair amount of work.=A0 I would prefer to see more detailed statements about what the goals are.=A0

So for instance, taking each bullet point in turn:

=A0=A0 o=A0 Minimize false positives.

Positive for what?=A0 Phish?=A0 Positive authentication?

=A0=A0 o=A0 Provide robust authentication reporting.

By whom to whom?=A0 And what is authentication reporting in this context?

=A0=A0 o=A0 Reduce the amount of successfully delivered phish.

Is the intent here solely to avoid phish or also spam?=A0 Are we talking about "fraudulant and/or dangerous email?"=A0 I'm= nitpicking on phish because if this is a major high level goal, I want to understand what precisely you intend to minimize.

Section 3.2 really belongs in Security Considerations.

Also, a nit: these are goals not requirements, unless we can say who is making them requirements.=A0 And if it's not the IETF, then let&= #39;s back off that language.

Section 3.3 point 3 is full of forward references and use of jargon like "joe job" attacks, leading one straight to Google.=A0 I&= #39;m not documenting the rest at the moment, but the document is laden with this sort of thing, and really needs to be unladen.

Section 3.4:

1.=A0 is not a requirement, but an assertion.
2.=A0 is all mixed up.=A0 What precisely is the requirement?=A0 The las= t sentence belongs in another sentence.
3.=A0 Is not really a requirement but a statement that DNS will be used.=A0
5.=A0 "No action" is used without explaining what that means.= =A0 I know that sounds obvious "take no action", but does that mean HALT= ?=A0 Let the message through?=A0 What?
6.=A0 This is obvious.=A0 The reverse is hard and necessary.=A0 How can= a policy be applied that functions across an entire domain?
7.=A0 I don't understand why this is in the doc at all, and why it = is a requirement.
8.=A0 This requires that state be maintained on a receiver, and could be an attack vector.
9.=A0 Is not a requirement.
10,11,12.=A0 Requirements for aggregate report without actually saying what is being aggregated or reported.
14.=A0 If we're using DNS, this is obvious.

Section 4:

The glossary needs to be moved forward!!!

Organizational Domain: Question: what would happen if two sites develop two separate lists of public suffixes that don't match?=A0 = In particular, could a parent domain assert authority for messages sent from a child domain?=A0 What are the implications if a TLD is not listed?=A0 Does anyone know the breakdown of the Egyptian domains in Arabic?

4.2: Summary=A0 =3D> Overview.=A0 This also needs to be moved forwar= d, although if you rewrite and shrink Section 3 as I recommend, it will have that effect ;-)

Section 5:

A Domain Owner advertises DMARC participation by adding a DNS TXT
=A0=A0 record (described in Section 6) {R3, R15, R16} to one or more sending
=A0=A0 domains under its direct or indirect control (e.g. operated by a
=A0=A0 delegate by agreement with the Domain Owner).=A0

I think you mean "A Domain Owner advertises DMARC participation of one or more sending domains by advertising them through a DNS TXT record."

=A0=A0 A Mail Receiver MUST consider an arriv= ing message to pass the DMARC
=A0=A0 test if and only if one or more of the underlying message
=A0=A0 authentication mechanisms pass with proper identifier alignment.

Please define what the test actually IS!!

Later on:

=A0=A0 A Domain Owner that does not advertise= an SPF policy or sign with
=A0=A0 DKIM is making an implicit statement that the use cases those<= br> =A0=A0 protocols satisfy are not to be considered when determining whether
=A0=A0 or not the message under evaluation is valid.=A0 For example, = not
=A0=A0 publishing an SPF policy is an implicit message from Domain Owners to
=A0=A0 Mail Receivers that successful path authorization is not to be taken
=A0=A0 as sufficient evidence that the Domain Owner authorized the message.

Either I'm confused or this example is backwards.=A0 How can you do successful path authorization in the first place without SPF?

Section 8.2:

For example, a TXT resource record at
=A0=A0 "*._report._dmarc.example.com" containing at least "v=3DDMARC= 1"
=A0=A0 confirms that example.com is willing to receive DMARC reports for any
=A0=A0 domain.

Any domain or any CHILD domain?

Section 8.4:

That last comment in (2) seems to indicate that there should be a way to collapse the ABNF, but I leave it to Dave who is Mr. ABNF as to whether that is the right thing to do (I guess the tradeoff would be a mandatory order).

Section 9:

Steps 2 and 4 look both repetitive and they conflict.=A0 One says that the record must START with a version and the other simply requires its inclusion.=A0 ???

Section 11.3 as an example:

=A0=A0 Attention must be paid to the possible presence of the "pct" tag in
=A0=A0 the DMARC policy record.=A0 If the tag is present, the Mail Receiver
=A0=A0 MUST NOT enact the requested policy ("p" tag or &quo= t;sp" tag") on more
=A0=A0 than the stated percent of the totality of affected messages.<= br>

The first sentence is chatty, and reflects the overall informal tone of the document.=A0 This is a technical specification and not a casual conversation.

Section 12.2.1: EMail

Please justify your normative language in the following cases:

=A0=A0 In the case of a "mailto" UR= I, the Mail Receiver SHOULD communicate
=A0=A0 reports using the method described in [STARTTLS].

As a matter of security, RFC-2119 gives license to you to use MUST here.=A0 Why not do it?

=A0=A0 The aggregate data MUST be present usi= ng the media type "application/
=A0=A0 gzip", and the filenames SHOULD be constructed using the following
=A0=A0 ABNF:

On what basis according to RFC-2119=A0 MUST aggregate data be compressed?
Separately, why is the filename at all important, requiring a SHOULD?

Section 13:

=A0=A0 o=A0 Is able to send and/or receive re= ports at least daily;

=A0=A0 o=A0 Is able to send and/or receive reports using "mailto= " URIs;

Receive?=A0 Eh?=A0 How can one receive a report at least daily?=A0 Usin= g a URI?

Section 15 Security Considerations:

15.1, 15.2, and elsewhere don't follow the best current practices specified in RFC-3552, and those that have evolved since.=A0 State the threat and state the remediation (if any).=A0 I would split 15.4 to two points: there is the potential for a downgrade attack as SPF is only as strong as its weakest link in the path, and that a poor deployment of SPF can lead to garbage getting through.

I don't really see 15.9 as a security consideration, but more of a deployment consideration.

15.10.4:

Open transport mechanisms should be
=A0=A0 avoided.

"Unencrypted"?

15.12:

Again, poorly stated threat.=A0 Remediation seems to suggest DNSSEC but then doesn't require its use.=A0 At the same time, the text giv= es license to implementations to defer message processing when DNSSEC isn't deployed.=A0 This leads to interoperability issues.=A0 Be cle= ar: either require DNSSEC or don't but don't NOT require it and the= n recommend deferrals.

Eliot