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

---------- Forwarded 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>


 I've been asked to take a look at the DMARC spec.  Let me start by saying
that I know that you guys have running code.  I beg your indulgence and ask
you to read through.  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.  To start with, the
requirements section is horribly confused.  Some are not requirements but
specifications, others are vague.  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.  Whatever.

The whole section needs to be replaced with something simpler, like:

[1]  Here is what the specification is out to accomplish (and not
accomplish).
[1a] A formal description of the threat model
[2]  Here are the assumptions we make about sender capabilities
[3]  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.  It needn't be
long; perhaps a page or two.  Yes, include a pretty ASCII picture (maybe a
swimming pool diagram or two).

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

The Security Considerations section needs a serious edit cut.

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

Sections 2.1 – 2.3 are advertisements for the mechanism, and largely
vacuous.  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.  Particularly off putting is the statement:

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


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

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

So for instance, taking each bullet point in turn:

   o  Minimize false positives.


Positive for what?  Phish?  Positive authentication?

   o  Provide robust authentication reporting.


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

   o  Reduce the amount of successfully delivered phish.


Is the intent here solely to avoid phish or also spam?  Are we talking
about "fraudulant and/or dangerous email?"  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.  And if it's not the IETF, then let'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.  I'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.  is not a requirement, but an assertion.
2.  is all mixed up.  What precisely is the requirement?  The last sentence
belongs in another sentence.
3.  Is not really a requirement but a statement that DNS will be used.
5.  "No action" is used without explaining what that means.  I know that
sounds obvious "take no action", but does that mean HALT?  Let the message
through?  What?
6.  This is obvious.  The reverse is hard and necessary.  How can a policy
be applied that functions across an entire domain?
7.  I don't understand why this is in the doc at all, and why it is a
requirement.
8.  This requires that state be maintained on a receiver, and could be an
attack vector.
9.  Is not a requirement.
10,11,12.  Requirements for aggregate report without actually saying what
is being aggregated or reported.
14.  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?  In particular, could a
parent domain assert authority for messages sent from a child domain?  What
are the implications if a TLD is not listed?  Does anyone know the
breakdown of the Egyptian domains in Arabic?

4.2: Summary  => Overview.  This also needs to be moved forward, 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
   record (described in Section 6) {R3, R15, R16} to one or more sending
   domains under its direct or indirect control (e.g. operated by a
   delegate by agreement with the Domain Owner).


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

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


Please define what the test actually IS!!

Later on:

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


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


Section 8.2:

For example, a TXT resource record at
   "*._report._dmarc.example.com" containing at least "v=DMARC1"
   confirms that example.com is willing to receive DMARC reports for any
   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.  One says that the
record must START with a version and the other simply requires its
inclusion.  ???


Section 11.3 as an example:

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


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

Section 12.2.1: EMail

Please justify your normative language in the following cases:

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


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

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


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


Section 13:

   o  Is able to send and/or receive reports at least daily;

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


Receive?  Eh?  How can one receive a report at least daily?  Using 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.  State the threat and state
the remediation (if any).  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
   avoided.


"Unencrypted"?

15.12:

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

Eliot