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

[Eliot Lear <[e-mail]>]

Hi Murray,

Thanks for your response.  Please see below.

On 7/5/13 10:08 AM, Murray S. Kucherawy wrote:
> 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.

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

Thanks.  You're covering a lot of ground.  I think for simple RFCs it's
okay to cram in an example or two.  This is, at least for me, just
beyond that.

>  
>
>     The Security Considerations section needs a serious edit cut.
>
>
> Can you be more specific?

You've dealt with it below.

>  
>
>     Section 4:
>
>     The glossary needs to be moved forward!!!
>
>
> It has, by virtue of the cleanup in Sections 2 and 3.

Good!

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

I think we may need to iterate on this, but not in the middle of this
document.  My current thinking is that this is actually a contractual
problem, at least in part.  No parent should assert for a child for
which there is no administrative control.  On the other hand, there is
no way within DNS for this relationship to be asserted on a technical
basis.  It's enough of an annoyance, however, that it really needs repair.

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

I suggest that you be a bit more clear about what proper identifier
alignment is, and perhaps what pass means.  I seem to recall a header
for this ;-)  Referencing the terms there would probably be sufficient.

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

I think there is a simpler way to say all of this.  We can easily
enumerate the cases and stick them into a table.  Fill in the blanks.

Condition
	DMARC Action
DKIM and SPF pass
	pass
DKIM and SPF fail
	fail
DKIM passes and SPF fails
	
DKIM fails and SPF passes
	
SPF passes DKIM not present
	pass
DKIM passes, SPF not present
	pass
neither DKIM nor SPF present
	



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

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

No, but you may want to indicate why it's a SHOULD and not a MUST, and
encourage use of STARTTLS.
>  
>
>
>>        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.

I think you just made a good argument for SHOULD.  Again, please review
the criteria for a MUST.  They're pretty stringent.

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

Ok, but isn't that just a receiver implementation problem?  I think it's
fine to give advice like this, but I don't see it requiring normative
language.
>  
>
>  
>
>
>     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.

This in itself requires a security consideration and remediation. 
Suppose I start sending vast numbers of bogus reports to you.  What's
the remediation?

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

Thanks!

Eliot