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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 5 Jul 2013 01:08:09 -0700

On Tue, May 21, 2013 at 3:09 AM, Eliot Lear <[email-masked]> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 5 Jul 2013 01:34:05 -0700

Hi SM,

As I said with Eliot's review, thanks for looking at this so early on.  I'm
going to chop a chunk of what you said out about the heavy requirements and
"marketing" since much of it will be slashed in the next version.  As for
what's left:

On Thu, May 23, 2013 at 2:55 AM, SM <[email-masked]> wrote:

>
> The terminology section mentions terms such as "cousin domains", "domain
> owner", etc.  Although such terms may be popular I don't think that it is a
> good idea to use them in a protocol document as they can be ambiguous.
>

Can you make other suggestions?  I think the first one is not ambiguous in
general, but we're very clear on defining and using the second.

>
> In Section 5:
>
>
>   "A Mail Receiver MUST consider an arriving message to pass the DMARC
>    authentication mechanisms pass with proper identifier alignment."
>
> The above conveys the idea.  It does not provide adequate information for
> the implementer.
>

The details are further down in the document.  Section 5 is setting the
stage for what comes later.  It's more overview than substance.

>
>   "A Mail Receiver implementing the DMARC mechanism MUST make a best-
>    effort to adhere to the Domain Owner's published DMARC policy when a
>    message fails the DMARC test."
>
> The above uses a "MUST" to tell people that they ought to make a
> best-effort.  In my opinion that is incorrect usage of RFC 2119 key words.
>

I agree, this would likely be caught during more formal reviews as well.  I
think "MUST make" can just be "makes".

>
>   "Mail Receivers MAY deviate from a Domain Owner's published policy
>    during message processing and SHOULD make available the fact and
>    reason of the deviation to the Domain Owner via feedback reporting."
>
> I read the above as "if you do not do what I say you have to provide me
> with a justification".  Let me rewrite the text:
>
>   "Mail Receivers deviating from a Domain Owner's published policy
>    during message processing and MUST make available the fact and
>    reason of the deviation to the Domain Owner via feedback reporting."
>
> If that text is not acceptable to mail receivers the RFC 2119 SHOULD will
> have the same effect.
>

SHOULD is appropriate.  There can be local policy reasons for not revealing
such details via feedback.

>
> In Section 7:
>
>   "When this is done, the DNS domain name thus recorded MUST be encoded as
> an
>    A-label, as described in Section 2.3 of [IDNA]."
>
> The above is under "policy enforcement considerations".  It should be in a
> section discussing the DNS aspects of the specification.
>

Why?  The context is the construction of an RFC5451 header field, not
something about DNS.

>
> Section 8.2 is about "Verifying External Destinations".  If I am not
> mistaken, IETF specifications are not about imposing a specific method.
>  Section 8.2 sounds like a tutorial for the implementer instead of a
> definition of what the "DMARC policy string" means.
>
>
I disagree; a specification is indeed about describing a specific method.
Tutorials for implementers appear throughout various documents we produce,
one of which you are working on in another working group right now.  :-)

>   "A report receiver MUST publish such a record in its DNS if it wishes
>    to receive reports for other domains."
>
> The RFC 2119 usage is inappropriate here.  I would put it after the
> high-level view (see Eliot's message) of how DMARC works.
>

It's fine to drop this to "publishes".  I believe "MUST publish" is also
technically correct, but Pete has described it as "unnecessary shouting" in
the past.

>
> In Section 8.3:
>
>   "The report SHOULD include the following data:
>
>    o  Enough information for the report consumer to re-calculate DMARC
>       disposition based on the published policy, message dispositon, and
>       SPF, DKIM, and identifier alignment results. {R12}"
>
> "enough information" is an ambiguous description of what the report should
> include.
>

That SHOULD looks more like requirements language, and I agree the bullet
list is non-specific.  The details are in the section containing the XML
syntax.  We'll adjust.

>
> In Section 11.2:
>
>   "Heuristics applied in the absence of use by a Domain Owner of either
>    SPF or DKIM (e.g., [Best-Guess-SPF]) SHOULD NOT be used, as it may be
>    the case that the Domain Owner wishes a Message Receiver not to
>    consider the results of that underlying authentication protocol at
>    all."
>
> The reference would have to be normative.
>

Is that true?  I would think making normative something one SHOULD NOT use
seems contradictory.

>
> In Section 11.3:
>
>   'If email is subject to the DMARC policy of "quarantine", the Mail
>    Receiver SHOULD quarantine the message.  If the email is not subject
>    to the "quarantine" policy (e.g., due to the "pct" tag), the Mail
>    Receiver SHOULD apply local spam classification as normal.'
>
> The usage of RFC 2119 key words in the above is incorrect.
>

Why?

>
> In Section 12.2.1:
>
>  'In the case of a "mailto" URI, the Mail Receiver SHOULD communicate
>    reports using the method described in [STARTTLS].'
>
> Has the usual STARTTLS issues been taken into consideration for the RFC
> 2119 recommendation?
>

Such as what?

>
>   "The aggregate data MUST be an XML file subjected to GZIP compression.
>
>    ABNF:"
> In Section 12.2.2 it mentioned that:
>
>   'Where an "http" or "https" method is requested in a Domain Owner's
>    URI list, the Mail Receiver MAY encode the data using the
>    "application/gzip" media type ([GZIP]) or MAY send the Appendix C
>    data uncompressed or unencoded.'
>
> The data exchange format depends on the URI scheme being used.  In my
> opinion that makes the implementation more complex.
>

I don't agree, but I think the more important point is that the two
sections disagree on whether compression is required.

>
>   'For the GZIP file itself, the extension MUST be "gz"; for the XML
>    report, the extension MUST be "xml".'
>
> I would ask why such a RFC 2119 requirement is in the draft.
>

For interoperability, of course.  What's the issue here?

>
>   "Email streams carrying DMARC feedback data MUST conform to the DMARC
>    mechanism, thereby resulting in an aligned "pass" (see Section 4.3)."
>
> As far as I am aware the IETF does not do conformance.
>

It doesn't do conformance levels, as far as I'm aware.  But you either
conform to the standard or you do not.  Are you keying on the word
"conform" or is there more going on here?

>
>   'The RFC5322.Subject field for individual report submissions SHOULD
>    conform to the following ABNF:'
>
> The Subject field is specified as structured text in the above.
>

Is that bad?

>
> In Section 12.2.2:
>
>   "The header portion of the POST or PUT request SHOULD contain a
>    Subject field as described in Section 12.2.1."
>
> This sounds like sending RFC 5322 formatted messages over HTTP.
>

Is that bad?

> In Section 15.8:
>
>   "Many systems are able to scan the SMTP reply text to determine the
>    nature of the rejection, thus providing a machine-detectable reason
>    for rejection allows automated sorting of rejection causes so they
>    can be properly addressed."
>
> I don't think that it is a good idea to discuss about that as part of a
> protocol specification.
>

Why?

>
> I suggest giving careful consideration to privacy.  The draft discusses
> about that in Section 15.10.1.  The draft would require a detailed review
> to understand what information is being exchanged and how that can affect
> users.
>

What issue should we cover that 15.10.1 does not already?

>
> In Section 15.12:
>
>   "The DMARC mechanism and its underlying technologies (SPF, DKIM)
>    depend on the security of the DNS.  To reduce the risk of subversion
>    of the DMARC mechanism due to DNS-based exploits, serious consideration
>    should be given to the deployment of DNSSEC in parallel to the
> deployment
>    of DMARC."
>
> I would ask whether anyone who has deployed this mechanism is actually
> using DNSSEC.  If not the above is not saying anything to ensure secure use
> of the protocol.
>

I don't think it's pragmatic to demand use of DNSSEC because of the obvious
chicken-and-egg problem.  However, for a system that is so heavily reliant
on the DNS being stable and secure, it seems wrong not to mention this.

>
>   "S/MIME, or Secure Multipurpose Internet Mail Extensions, is a
>    standard for encryption and signing of MIME data in a message.  This
>    was suggested and considered as a third security protocol for
>    authenticating the source of a message."
>
> I could not understand the relationship between S/MIME and what this
> specification attempts to do.
>

S/MIME can authenticate part of a message and associate it with a user or
role.  DKIM and SPF can do the same.  The relationship seems obvious to
me.  The question will be asked "Why didn't you also include support for
FOOBAR?" and it seemed appropriate to make it clear that we did, even if
the result is that the idea was discarded.

>
>   "It has been suggested in several message authentication efforts that
>    the Sender header field be checked for an identifier of interest, as
>    the standards indicate this as the proper way to indicate a re-
>    mailing of content such as through a mailing list.  Most recently, it
>    was a protocol-level option for DomainKeys, but on evolution to DKIM,
>    this property was removed."
>
> That discussion would be better in a DKIM-related document instead of
> adding it to this draft.
>

I don't agree, because "Use the Sender field!" came up during both the
private and public portions of the evolution of this work.  As with S/MIME,
it seems appropriate to document history rather than repeat it.

>
>   'DMARC has been characterized as a "super-ADSP" of sorts.'
>
> It is not a good idea to include criticism of other protocols in a draft
> that specifies a protocol unless it is relevant to the protocol being
> specified.
>

Just about every BoF that tries to tackle a problem for which prior
attempts have failed includes an analysis of why those prior attempts
failed.  I don't think this is any different, and I think it provides a
fair treatment of the issues with ADSP that have been showstoppers for a
lot of people.

> I suggest dropping the idea of using the "public suffix list" as previous
> attempts to use it have not been successful in the IETF.
>

The revised version makes it clear that we don't like public suffix any
better than the rest of the IETF does, and will be happy to adopt a
replacement solution as soon as there is one.

-MSK

---

From: Eliot Lear <[email-masked]>
Date: Fri, 05 Jul 2013 11:09:11 +0200

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.

> Can you be more specific?

You've dealt with it below.

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

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

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

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

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

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

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

Thanks!

Eliot

---

From: "John Levine" <[email-masked]>
Date: 5 Jul 2013 18:52:20 -0000

>>  I've been asked to take a look at the DMARC spec.

Your original note with the comments never made it to the DMARC list
(I checked the archives.)  Could someone send it along so we don't
have to reverse engineer it from the meta-comments?

Tnx.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 5 Jul 2013 12:10:31 -0700

Wasn't it this?
http://www.ietf.org/mail-archive/web/dmarc/current/msg00292.html

I don't have anything from him prior to that.

---

From: SM <[email-masked]>
Date: Fri, 05 Jul 2013 11:05:58 -0700

Hi Murray,
At 01:34 05-07-2013, Murray S. Kucherawy wrote:
>As I said with Eliot's review, thanks for looking at this so early 
>on.  I'm going to chop a chunk of what you said out about the heavy 
>requirements and "marketing" since much of it will be slashed in the 
>next version.  As for what's left:

Ok.

I would have to read draft-kucherawy-dmarc-base-00 to remember the 
context of my previous comments.  I'll respond quickly instead.

>Can you make other suggestions?  I think the first one is not 
>ambiguous in general, but we're very clear on defining and using the second.

I'll have to go and read before suggesting anything.  Let's put this 
one on hold and get back to it later.

>  The details are further down in the document.  Section 5 is 
> setting the stage for what comes later.  It's more overview than substance.

I suggest not putting requirements in a section which provides an 
overview.  Barry and Pete commented about yelling in a WG.  I suggest 
taking those comments into consideration.    As a meta-comment about 
setting the stage I suggest writing the proposal as a mechanism.  You 
could then drop text, reorganize it, etc. to come up with a leaner 
version which specifies the mechanism and avoids the usual headaches.

>I agree, this would likely be caught during more formal reviews as 
>well.  I think "MUST make" can just be "makes".

Yes (see above).

>I read the above as "if you do not do what I say you have to provide 
>me with a justification".  Let me rewrite the text:
>
>If that text is not acceptable to mail receivers the RFC 2119 SHOULD 
>will have the same effect.
>
>
>SHOULD is appropriate.  There can be local policy reasons for not 
>revealing such details via feedback.

What I meant is that the proposal is telling mail receivers what to 
do.  The matter is entirely a local policy 
issue.  draft-kucherawy-dmarc-base-00 is intended as a Standards 
Track document.  The draft is doing policy stuff and trying to set 
conformance.  There has been previous similar efforts.  I would 
describe them as controversial and subject to interpretation.  I 
would scope the work to keep the implementation and policy parts 
separate so that you have a tightly-written specification.

>
>
>In Section 7:
>
>   "When this is done, the DNS domain name thus recorded MUST be encoded as an
>The above is under "policy enforcement considerations".  It should 
>be in a section discussing the DNS aspects of the specification.
>
>
>Why?  The context is the construction of an RFC5451 header field, 
>not something about DNS.

I guess that we are reading "policy enforcement considerations" 
differently.  The context is as what you wrote above.  What I was 
suggesting is to separate policy from how the DMARC code is supposed 
to work.  You could take the RFC 5451 approach to simplify the draft.

>mistaken, IETF specifications are not about imposing a specific 
>method.  Section 8.2 sounds like a tutorial for the implementer 
>instead of a definition of what the "DMARC policy string" means.
>
>
>I disagree; a specification is indeed about describing a specific 
>method.  Tutorials for implementers appear throughout various 
>documents we produce, one of which you are working on in another 
>working group right now.  :-)

I disclaim any knowledge of any other working group. :-)

I have been reading some specifications (not mail-related) and some 
reviews recently.  I don't think that the Internet Engineering Tooth 
Fairy will agree with the following; sometimes a proposal specifies a 
method and gets into details which turns the proposal into a guide 
about a specific implementation.  A Standards Track document is about 
interoperability and not about specifying how the implementor should do things.

>It's fine to drop this to "publishes".  I believe "MUST publish" is 
>also technically correct, but Pete has described it as "unnecessary 
>shouting" in the past.

Yes.

>"enough information" is an ambiguous description of what the report 
>should include.
>
>
>That SHOULD looks more like requirements language, and I agree the 
>bullet list is non-specific.  The details are in the section 
>containing the XML syntax.  We'll adjust.

As a quick reaction this is fixable.

>Is that true?  I would think making normative something one SHOULD 
>NOT use seems contradictory.

I missed the "e.g.".  You could leave it as it as informative.  I 
would remove the example, or that entire paragraph, and focus on the 
technologies you are using to design DMARC.

>The usage of RFC 2119 key words in the above is incorrect.

If I recall correctly, I wrote that as I thought that the above 
dictates local policy.  You could restate this in terms of 
information the publisher is trying to convey.  I would remove the 
"SHOULD apply local spam classification" as the draft is then trying 
to solve the spam problem.

>Has the usual STARTTLS issues been taken into consideration for the 
>RFC 2119 recommendation?
>
>
>Such as what?

The trust path is usually broken for STARTTLS.  It's like using 
self-signed certificates.    There is also an ambiguity, if I recall 
correctly, in the specification.

>The data exchange format depends on the URI scheme being used.  In 
>my opinion that makes the implementation more complex.
>
>

Ok.

>For interoperability, of course.  What's the issue here?

That sounds using MIME sniffing.  It's easier to defer to the 
relevant specification instead of setting a requirement here.

>It doesn't do conformance levels, as far as I'm aware.  But you 
>either conform to the standard or you do not.  Are you keying on the 
>word "conform" or is there more going on here?

Yes, I was keying on the word "conform".  The "standard" tells you 
what you need to know to achieve interoperability.  My reading of the 
above is that you want an aligned "pass" and you worked your way back 
to get there.

>The Subject field is specified as structured text in the above.

The specification is re-purposing ancient technology. :-)  The short 
answer is that it is not good.    I was not keen about previous 
proposals taking such an approach.  It works if you do it on a 
controlled environment.  You might see problems as you scale it.

>This sounds like sending RFC 5322 formatted messages over HTTP.

I don't have enough information as I write this to say that it is 
bad.  The proposal reminds me of another specification and that's not 
a good sign. :-)

>I don't think that it is a good idea to discuss about that as part 
>of a protocol specification.
>
>Why?

The draft getting into heuristics.  This takes you away from protocol 
specification to things people do because "it works for them".  The 
straight answer is that I don't really know as it is a matter of 
whether the heuristics not working is really an edge case or 
something to seriously consider.

>I suggest giving careful consideration to privacy.  The draft 
>discusses about that in Section 15.10.1.  The draft would require a 
>detailed review to understand what information is being exchanged 
>and how that can affect users.
>

I flagged this as "things to look out for".  It's easier if you have 
people who will review the privacy considerations during the initial 
work.  Given all the privacy discussions that are going on I suggest 
looking into it carefully.  I don't have any idea of whether 
everything is covered adequately as I prefer not to put too much time 
into a review at this stage.

>    should be given to the deployment of DNSSEC in parallel to the deployment
>    of DMARC."
>
>I would ask whether anyone who has deployed this mechanism is 
>actually using DNSSEC.  If not the above is not saying anything to 
>ensure secure use of the protocol.
>
>I don't think it's pragmatic to demand use of DNSSEC because of the 
>obvious chicken-and-egg problem.  However, for a system that is so 
>heavily reliant on the DNS being stable and secure, it seems wrong 
>not to mention this.

The chicken-and-egg problem has been solved.  You could have DNSSEC 
under Security Considerations.

>S/MIME can authenticate part of a message and associate it with a 
>user or role.  DKIM and SPF can do the same.  The relationship seems 
>obvious to me.  The question will be asked "Why didn't you also 
>include support for FOOBAR?" and it seemed appropriate to make it 
>clear that we did, even if the result is that the idea was discarded.

I see.

>That discussion would be better in a DKIM-related document instead 
>of adding it to this draft.
>
>
>I don't agree, because "Use the Sender field!" came up during both 
>the private and public portions of the evolution of this work.  As 
>with S/MIME, it seems appropriate to document history rather than repeat it.

Ok.

>It is not a good idea to include criticism of other protocols in a 
>draft that specifies a protocol unless it is relevant to the 
>protocol being specified.
>
>attempts have failed includes an analysis of why those prior 
>attempts failed.  I don't think this is any different, and I think 
>it provides a fair treatment of the issues with ADSP that have been 
>showstoppers for a lot of people.

It happens. :-)

You could leave it for now and drop the text before publication.

>I suggest dropping the idea of using the "public suffix list" as 
>previous attempts to use it have not been successful in the IETF.
>
>The revised version makes it clear that we don't like public suffix 
>any better than the rest of the IETF does, and will be happy to 
>adopt a replacement solution as soon as there is one.

I would flag the "public suffix list" on a Last Call so that nobody 
says that they were not aware that it is being standardized.

Regards,
-sm

---

From: "John R Levine" <[email-masked]>
Date: 5 Jul 2013 15:25:15 -0400

> I don't have anything from him prior to that.

Oh OK, I didn't realize it was from six weeks ago, so it aged out of the 
news spool where I keep list mail.

R's,
John

---

From: Franck Martin <[email-masked]>
Date: Sat, 6 Jul 2013 08:14:08 +0000

On Jul 5, 2013, at 11:05 AM, SM <[email-masked]> wrote:

>> I don't think that it is a good idea to discuss about that as part of a protocol specification.
>> 
>> Why?
> 
> The draft getting into heuristics.  This takes you away from protocol specification to things people do because "it works for them".  The straight answer is that I don't really know as it is a matter of whether the heuristics not working is really an edge case or something to seriously consider.
> 
There is not much standardization of response codes from MTAs. There are extended response codes, but then you cannot deduct from them, if the problem is due to DMARC or other security policies. If I'm not mistaken, take the case of Facebook, refusing an email because you are not a friend of the recipient... Or the same error code could indicate SPF or DKIM or other protocol failure... Having the word DMARC in the text of the error message gives a lot of information for debugging a specific email. Consider also the error could be generated after a forwarder is trying to send an email... Without a proper hint of what is the reason of the reject it is very hard to know what really happened for a specific email.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 06 Jul 2013 10:50:35 -0700

On 7/5/2013 1:34 AM, Murray S. Kucherawy wrote:
> On Thu, May 23, 2013 at 2:55 AM, SM <[email-masked]
> <mailto:[email-masked]>> wrote:
>     The terminology section mentions terms such as "cousin domains",
>     "domain owner", etc.  Although such terms may be popular I don't
>     think that it is a good idea to use them in a protocol document as
>     they can be ambiguous.
>
>
> Can you make other suggestions?  I think the first one is not ambiguous
> in general, but we're very clear on defining and using the second.

I'm astonished to discover that google does not readily produce major 
listings of a definition of cousin domain. (Interestingly, the dmarc 
base draft showed up pretty high in the search...)

Anyhow, I think that means a) we have to create our own definition, and 
b) it's worth being fairly careful about the text of the definition, 
since there's a chance it will become popular...

First listing I found strikes me as logical but wholly inadequate, in 
terms of interesting attacks:

      http://www.informit.com/articles/article.aspx?p=1190114

      "we defined a cousin domain name as one that contains the 
candidate domain name in its entirety, with additional words either 
prefixed or appended to the candidate domain name."

A squib from the book gets the idea, but isn't quite sufficient as a 
'definition':

      Phishing and Countermeasures: Understanding the Increasing Problem
      of ...;  edited by Markus Jakobsson, Steven Myers

      "phisher regisers a domain name similar to the targeted domain, 
such as 'commerceflaw.com' instead of 'commerceflow.com'."

A variant of this one shows up in a dhs.gov document:

      http://www.cyber.st.dhs.gov/docs/phishing-dhs-report.pdf

      "domain name controlled by a phisher that isdeceptively similar to
       a legitimate domain name, such as
       www.commerceflowsecurity.cominstead of www.commerceflow.com."

So in looking these over, I find myself liking the phrase "deceptively 
similar".  Hence I'll propose:

      A cousin domain is a registered domain name that is deceptively 
similar to a target domain name.  The target domain is familiar to many 
end-users, and therefore imparts a degree of trust.  The deceptive 
similarity can trick the user by embedding the essential parts of the 
target name, in a new string, or it can use some variant of the target 
name, such as replacing 'i' with '1'.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: SM <[email-masked]>
Date: Sat, 06 Jul 2013 11:01:40 -0700

Hi Frank,
At 01:14 06-07-2013, Franck Martin wrote:
>There is not much standardization of response codes from MTAs. There 
>are extended response codes, but then you cannot deduct from them, 
>if the problem is due to DMARC or other security policies. If I'm 
>not mistaken, take the case of Facebook, refusing an email because 
>you are not a friend of the recipient... Or the same error code 
>could indicate SPF or DKIM or other protocol failure... Having the 
>word DMARC in the text of the error message gives a lot of 
>information for debugging a specific email. Consider also the error 
>could be generated after a forwarder is trying to send an email... 
>Without a proper hint of what is the reason of the reject it is very 
>hard to know what really happened for a specific email.

That is usually know as a local policy decision.  If I recall 
correctly the question of the sender knowing the reason for a mail 
delivery failure was discussed in another working group.

I understand the use case mentioned above.  I would look at the draft 
in terms of a standard for the Internet, if that is the intended 
purpose, instead of a document about how to know why a message is 
considered as spam.

Regards,
-sm

---

From: Matt Simerson <[email-masked]>
Date: Sat, 6 Jul 2013 11:18:57 -0700

On Jul 6, 2013, at 10:50 AM, Dave Crocker <[email-masked]> wrote:

> IAnyhow, I think that means a) we have to create our own definition, and b) it's worth being fairly careful about the text of the definition, since there's a chance it will become popular...

+1

> So in looking these over, I find myself liking the phrase "deceptively similar".

+1

> Hence I'll propose:
> 
>     A cousin domain is a registered domain name that is deceptively similar to a target domain name.  The target domain is usually familiar to many end-users, and therefore imparts a degree of trust.  The deceptive similarity can trick the user by embedding the essential parts of the target name, in a new string, or it can use some variant of the target name, such as replacing 'i' with '1'.

I inserted the word 'usually'. 

In addition to providing basic examples, perhaps include the well defined and recognized terms: typosquatting, and IDN homographs?

https://en.wikipedia.org/wiki/Typosquatting
https://en.wikipedia.org/wiki/IDN_homograph_attack

Matt

---

From: Dave Crocker <[email-masked]>
Date: Sat, 06 Jul 2013 11:41:48 -0700

Thanks for the quick feedback.

some additional thoughts...

On 7/6/2013 11:18 AM, Matt Simerson wrote:
>> similar to a target domain name.  The target domain is *usually
>> *familiar to many end-users, and therefore imparts a degree of trust.
>>  The deceptive similarity can trick the user by embedding the
>> essential parts of the target name, in a new string, or it can use
>> some variant of the target name, such as replacing 'i' with '1'.
>

That's a kind of careful phrasing that makes sense for precise 
specification, but I think is actually distracting for the usage here.

That is, I think that extra qualifiers in definitions are, ummmm... 
usually distracting...

It's not that it's wrong; it's that I doubt it's as helpful as we'd like.

> In addition to providing basic examples, perhaps include the well
> defined and recognized terms: typosquatting, and IDN homographs?
>

yeah, and probably cite the dhs.gov text, to show some history to the 
key phrase.

d/

---

From: Elizabeth Zwicky <[email-masked]>
Date: Sat, 6 Jul 2013 18:52:22 +0000

I would say that the target domain is familiar to the users under attack.

	Elizabeth

On 7/6/13 11:41 AM, "Dave Crocker" <[email-masked]> wrote:

>_______________________________________________
>dmarc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dmarc

---

From: Matt Simerson <[email-masked]>
Date: Sat, 6 Jul 2013 12:01:31 -0700

On Jul 6, 2013, at 11:41 AM, Dave Crocker <[email-masked]> wrote:

>>> similar to a target domain name.  <snip> The deceptive similarity can trick the user by embedding the
> That's a kind of careful phrasing that makes sense for precise specification, but I think is actually distracting for the usage here.
> 
> That is, I think that extra qualifiers in definitions are, ummmm... usually distracting...
> 

Why not remove the domain familiarity part entirely? The essence of a cousin domain is not in the victims familiarity with the target domain name (which is less common than technophiles would hope) but in the victims familiarity with the organizational name in the domain.

Matt

---

From: Franck Martin <[email-masked]>
Date: Sat, 6 Jul 2013 19:15:14 +0000

On Jul 6, 2013, at 11:01 AM, SM <[email-masked]> wrote:

> That is usually know as a local policy decision.  If I recall correctly the question of the sender knowing the reason for a mail delivery failure was discussed in another working group.
> 
> I understand the use case mentioned above.  I would look at the draft in terms of a standard for the Internet, if that is the intended purpose, instead of a document about how to know why a message is considered as spam.
> 
Sure, but if you don't provide guidance in this document for implementors, where will you give it?

---

From: Franck Martin <[email-masked]>
Date: Sat, 6 Jul 2013 19:20:10 +0000

> Why not remove the domain familiarity part entirely? The essence of a cousin domain is not in the victims familiarity with the target domain name (which is less common than technophiles would hope)…
I think we should completely remove the notion of cousin domains or at least include it as part of a subset of grief, which is any email that claims to be from a brand regardless of the domain present in the From:

It seems to me, the miscreants do not care anymore what domain they put there... At least that's my experience.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 06 Jul 2013 12:20:08 -0700

> Why not remove the domain familiarity part entirely? The essence of a cousin domain is not in the victims familiarity with the target domain name (which is less common than technophiles would hope)…

well, /that's/ an interesting point.

comments?

d/

---

From: "John Levine" <[email-masked]>
Date: 7 Jul 2013 02:40:41 -0000

>> Why not remove the domain familiarity part entirely? The essence of a cousin domain is not in the
>victims familiarity with the target domain name (which is less common than technophiles would hope)
>but in the victims familiarity with the organizational name in the domain.
>
>

Sounds right to me.  paypaI.com is a phish because it resembles Paypal.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 6 Jul 2013 23:04:12 -0700

> name, such as replacing 'i' with '1'.
Seems a reasonable starting point.  Might also include a reference to
"homograph (literally, one appearance) attack".

-MSK

---

From: SM <[email-masked]>
Date: Sat, 06 Jul 2013 23:16:25 -0700

Hi Franck,
>implementors, where will you give it?

If the purpose of the document is to provide guidance for 
implementers about why a message is considered as spam I would put 
that guidance in the document.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 7 Jul 2013 00:20:37 -0700

On Fri, Jul 5, 2013 at 11:05 AM, SM <[email-masked]> wrote:

> setting the stage I suggest writing the proposal as a mechanism.  You could
> then drop text, reorganize it, etc. to come up with a leaner version which
> specifies the mechanism and avoids the usual headaches.
>

I think requirements, or perhaps they're better stated as "goals", explain
part of how we got here.  They're useful for providing background.

> What I meant is that the proposal is telling mail receivers what to do.
>  The matter is entirely a local policy issue.
>  draft-kucherawy-dmarc-base-00 is intended as a Standards Track document.
>  The draft is doing policy stuff and trying to set conformance.  There has
> been previous similar efforts.  I would describe them as controversial and
> subject to interpretation.  I would scope the work to keep the
> implementation and policy parts separate so that you have a tightly-written
> specification.
>

I think your change of "MAY deviate" to "deviating" is fine, but changing
MUST to SHOULD won't work.  MUST is not appropriate because the protocol
doesn't completely break if you don't take the action described here, and
there are certain to be operators that won't do what's specified because of
a need to keep internal mechanisms private.  That fits SHOULD nicely.

Any standards track document "sets conformance" by spelling out those parts
that are mandatory to implement.  I don't understand the objection there.

>> The above is under "policy enforcement considerations".  It should be in
>> a section discussing the DNS aspects of the specification.
>>
> suggesting is to separate policy from how the DMARC code is supposed to
> work.  You could take the RFC 5451 approach to simplify the draft.
>
>
Every operational environment is different.  Some will be able to take the
RFC5451 approach and some will not.  Shouldn't we provide operational
advice for both cases?

> reviews recently.  I don't think that the Internet Engineering Tooth Fairy
> will agree with the following; sometimes a proposal specifies a method and
> gets into details which turns the proposal into a guide about a specific
> implementation.  A Standards Track document is about interoperability and
> not about specifying how the implementor should do things.
>

This sort of protocol isn't completely deterministic.  At various
junctures, there are places where operational decisions get made.  It
strikes me that guidance when making those decisions is a good thing, and
its absence would be a bad thing.  We are asked to provide it more often
than not.

I think it all comes down to whether separating that sort of material out
into a separate document is a useful thing to do.  If doing so would mean
an implementer needs to hop back and forth between two documents just to
get the thing running, I'd say we've done the implementer a disservice.

I'm going to leave the rest for now and see what you think of the next
version.  I think a lot of this has been addressed, though I'm sure there
will be other things to discuss.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 7 Jul 2013 00:25:54 -0700

> "homograph (literally, one appearance) attack".
How's this, if you'll pardon the XML?

                    <t hangText="Cousin Domain:"> A registered domain name
that
                        is deceptively similar to a target name, which can
be a
                        domain name or the name of a known entity.  The
target
                        name is familiar to many end-users, and therefore
                        imparts a degree of trust.  The deceptive
similarity can
                        trick the user by embedding the essential parts of
the
                        target name in a new string (e.g.,
                        "companysecurity.example" to attack
"company.example"),
                        or it can use some variant of the target name, such
as
                        replacing 'i' with '1'.  This latter form is
sometimes
                        known as a "homograph attack".
</t>

---

From: Matt Simerson <[email-masked]>
Date: Sun, 7 Jul 2013 19:25:14 -0700

On Jul 7, 2013, at 12:25 AM, "Murray S. Kucherawy" <[email-masked]> wrote:

>                     <t hangText="Cousin Domain:"> A registered domain name that   
>                         is deceptively similar to a target name, which can be a   
>                         domain name or the name of a known entity.  The entity target
>                         imparts a degree of trust.  The deceptive similarity can  
>                         trick the user by embedding the essential parts of the    
>                         target entity name in a new string (e.g., 
>                         "companysecurity.example" to attack "company.example"),  
>                         or it can use some variant of the target entity name, such as    
>                         replacing 'i' with '1'.  This latter form is sometimes    
>                         known as a "homograph attack".  </t>                      

I simplified the description by removing the 'target' abstraction. There are legitimate purposes for cousin domains, such as helping poor spellers and heading off typosquatting. 

I don't think the distinction of end-users is helpful. It implies that some class of users are not susceptible to cousin domain attacks. There's ample evidence that is not the case. 

Matt

---

From: Matt Simerson <[email-masked]>
Date: Sun, 7 Jul 2013 19:27:23 -0700

Oh humbug, the formatting was stripped out.

<t hangText="Cousin Domain:"> A registered domain name that   
                       is deceptively similar the name of a known entity.  The entity
                       name is familiar to users and therefore 
                       imparts a degree of trust.  The deceptive similarity can  
                       trick the user by embedding the essential parts of the    
                       entity name in a new string (e.g., 
                       "companysecurity.example" to attack "company.example"),  
                       or it can use some variant of the entity name, such as 
                       replacing 'i' with '1'.  This latter form is sometimes    
                       known as a "homograph attack". </t>

---

From: Dave Crocker <[email-masked]>
Date: Sun, 07 Jul 2013 23:21:41 -0700

>> I don't think the distinction of end-users is helpful. It implies that some class of users are not susceptible to cousin domain attacks. There's ample evidence that is not the case.

I think the distinction between domain names and other kinds of names 
can be useful to make explicitly.  The use of 'target' is needed for 
referential disambiguation between the attacker's domain name and the 
one that is the basis for the attack.  However I do think "end-" isn't 
as helpful as I had intended; so 'users' should suffice.

Hence a few more tweaks:

<t hangText="Cousin Domain:"> A registered domain name that is
      deceptively similar to a target domain name or other name of a
      known entity.  The target name is familiar to many users, and
      therefore imparts a degree of trust.  The deceptive similarity can
      trick the user by embedding the essential parts of the target name
      in a new string (such as, "companysecurity.example" to attack
      "company.example"), or it can use some variant of the target name,
      such as replacing 'i' with '1', which is known as a "homograph
      attack".  </t>

d/

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 8 Jul 2013 12:54:42 +0000

I don't think it is just that the target domain is familiar to the users under attack. It is the "brand identity". That is, the users under attack may be familiar with the brand but not necessarily familiar with the exact domain that the brand/organization uses.

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Elizabeth Zwicky
> Sent: Saturday, July 06, 2013 2:52 PM
> To: Dave Crocker; Matt Simerson
> Cc: SM; [email-masked]; Murray S. Kucherawy; Eliot Lear
> Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's
> review of the DMARC spec)
> 
>

---

From: Steve Jones <[email-masked]>
Date: Mon, 8 Jul 2013 14:04:51 -0700

Do we have other definitions to cover deceptive names not similar to an
existing domain? If phishers are using CraftsmanOnline.com, and Sears using
other domains, is that a cousin domain or do we need a different term?

If it is considered a cousin domain because it plays on a known entity name
or brand identity...

<t hangText="Cousin Domain:"> A domain name that is
     deceptively similar to a registered domain name or other name
     associated with a known entity.  The target name may be familiar to
     many users, thereby imparting a degree of trust. The deceptive
similarity can
     trick the user by embedding the essential parts of the target name
     in a new string (such as, "companysecurity.example" to attack
     "company.example"); it can use some variant of the target name,
     such as replacing 'i' with '1', which is known as a "homograph
     attack;" or it may invent a plausible domain name based on the
     common name of a known entity or brand, such as "BrandAOnline.example,"
     where the entity actually uses other domain names such as
     "xyzcorp.example."
</t>

On Mon, Jul 8, 2013 at 5:54 AM, MH Michael Hammer (5304) <[email-masked]>wrote:

> I don't think it is just that the target domain is familiar to the users
> under attack. It is the "brand identity". That is, the users under attack
> may be familiar with the brand but not necessarily familiar with the exact
> domain that the brand/organization uses.
>
> Mike
>

---

From: Barry Leiba <[email-masked]>
Date: Mon, 8 Jul 2013 17:12:26 -0400

>      domain name or the name of a known entity.  The target
>      or it can use some variant of the target name, such as

If it's not too late to change the term "cousin domain" for this, I
suggest finding another term.  "Cousin" implies a legitimate relation,
which this isn't.  I would consider, say, "ibm.com" and "lotus.com" to
be cousin domains.  I might consider "microsoft.com", "hotmail.com",
and "skype.com" to be cousin domains.  Things that try to look like
they're related, but *aren't*, are what we're talking about here, and
I don't think of those as cousins.

Barry

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 08 Jul 2013 17:16:10 -0400

> I don't think of those as cousins.

Doppelganger domains.

Scott K

---

From: Steve Jones <[email-masked]>
Date: Mon, 8 Jul 2013 14:17:25 -0700

Interesting point - is there a small monograph on the taxonomy of deceptive
domain names kicking around out there? Could we split one off and forward
reference?

---

From: Matt Simerson <[email-masked]>
Date: Tue, 9 Jul 2013 16:35:52 -0700

On Jul 8, 2013, at 2:17 PM, Steve Jones <[email-masked]> wrote:

> >  <t hangText="Cousin Domain:"> <snip> </t>
> 

New Oxford American Dictionary, cousin:
	• a person belonging to the same extended family.
	• a thing related or analogous to another: the new motorbikes are not proving as popular as their four-wheeled cousins.

Having mulled this over, including time wearing my genealogist's hat, I heartily disagree that the term cousin implies any sense of legitimacy. In my experience, it is uncommon for people to distinguish between natural, step, adopted, foster, illegitimate, maternal, paternal, or even to describe the degree of a cousin. Until further inquiry or precision is requested, cousins are usually just cousins. 

> and "skype.com" to be cousin domains.

I think most anyone would accept that those are related domains. The term "cousin domain" is already established and already conveys a sense of illegitimacy.  Adding a new term to the mix with a slightly different meaning isn't going to help anyone, even if it is semantically more correct. 

> Things that try to look like they're related, but *aren't*, are what we're talking about here, and

But a cousin domain *is* related to the target domain, typically by appearance. It's just that as you pointed out earlier, the relationship is not legitimate. 

Matt