Re: [dmarc-ietf] Eliot's review of the DMARC spec

["Murray S. Kucherawy" <[e-mail]>]

On Tue, May 21, 2013 at 3:09 AM, Eliot Lear <[e-mail]> wrote:

>  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).
> [...]
>

Hi Eliot,

At long last, thanks for taking a look at this so early on.  We've finally
taken a run at processing this and other feedback and a new version should
be out before the embargo prior to IETF 87 kicks in.  I wanted to reply to
a few points as we do so to make sure we understand what you're saying and
can make sure the next version takes care of as much of this as practical.

First, much of the requirements summary stuff in what's now Sections 2 and
3 have been crushed down or eliminated.  Most of that is left over from
when the document was pre-IETF and needed a lot more introduction to
non-technical audiences.  We agree it doesn't need to be there in this
context.


>
> Please also intersperse the examples.  Otherwise the reader has to jump
> all over the document.
>
>
Added a note-to-self to revisit this issue.  The original approach was to
add them at the end in recipe or cookbook fashion.  We'll add some in the
middle and see if your idea improves things for the reader.


> The Security Considerations section needs a serious edit cut.
>

Can you be more specific?


> Section 4:
>
> The glossary needs to be moved forward!!!
>

It has, by virtue of the cleanup in Sections 2 and 3.


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

The public suffix list is far from an optimal solution to this
requirement.  There are some proposals on the table for doing this through
the DNS rather than the public suffix list, though that to some is only
marginally more palatable.  The DMARC people don't have any particular
marriage to public suffix, but it's the only option presently available.
This is discussed in one of the appendices.  We could make it more clear
that this is a known weak point and say we intend to replace it with
whatever comes along as soon as that thing is available.


>
> Section 5:
>
>    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!!
>

The test is the second half of that sentence, starting "one or more..."
What's missing?


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

Put another way: DMARC passes if either SPF or DKIM pass.  If your setup
for some reason can lead to SPF false positives (invalid "pass" results),
then if you're concerned about DMARC false positives, you would decline to
publish SPF.



> 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).
>

I think it's just another way of indicating the order doesn't matter.


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

There may be some operators that can't support STARTTLS yet for some
reason.  Do we need to preclude their participation?


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

The reports are substantially large in practice, at least among the
deployed base.  Compression is appropriate, and selecting one as the
required base form for doing so is also appropriate.   If two operators
want to use application/zip, they could do so, but they would not
interoperate with the base.


>
> Separately, why is the filename at all important, requiring a SHOULD?
>

The timestamps found in the filename are important to the receivers for
sorting and collating.




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

Won't blow up if it gets a 500Mb report over email once a day.

Can accept email.  (Just because you can send, doesn't mean you can
receive.)


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

Thanks, we'll take another full pass over this section with RFC3552's
advice in mind.

We hope to have a revision up in a week or so.

-MSK