Subject: [dmarc-ietf] draft-kucherawy-dmarc-base revision submitted

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 28 Oct 2014 15:44:29 -0700

Colleagues,

With apologies once again that it's taken so long, I have submitted the
base draft again to the datatracker.  It underwent what Eliot Lear calls a
"haircut", which is to say I spent a good chunk of time rearranging the
material, consolidating redundant sections, removing unnecessarily verbose
or unimportant text.  His sketch of a roadmap to doing so was very helpful
indeed.

There was only one technical change, and that was to remove all references
to IODEF since that's an aspect of the reporting component that is
completely unimplemented.  In the hopes of keeping the spec simple, it's
now gone.

Since we're past the I-D deadline, the ISE or Pete will have to approve its
addition to the datatracker, so it will magically appear at some point
soon, and then move forward in the publication process.

My thanks to all of you that took time to make haircut suggestions.

Onward,
-MSK

---

From: Brett McDowell <[email-masked]>
Date: Tue, 28 Oct 2014 19:09:37 -0400

Thanks Murray.  That was a really important step.  You continue to carry
the bulk of the email security standardization load on your shoulders, and
it is greatly appreciated!

Cheers,

-Brett

On Tue, Oct 28, 2014 at 6:44 PM, Murray S. Kucherawy <[email-masked]>
wrote:

> Since we're past the I-D deadline, the ISE or Pete will have to approve
> its addition to the datatracker, so it will magically appear at some point
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 28 Oct 2014 16:15:49 -0700

> it is greatly appreciated!

Hi Brett,

Thanks for your support.

I was going to say "I added a section that shows how we can finally solve
the display name problem" just to troll you specifically, but then I
thought better of it.  :-)

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 29 Oct 2014 13:37:07 -0700

> soon, and then move forward in the publication process.

It's now available in the datatracker:
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/

-MSK

---

From: Eliot Lear <[email-masked]>
Date: Thu, 30 Oct 2014 07:00:15 +0100

Murray,

You've clearly put a lot of work into updating this document, and there
are a substantial number of changes.  That means it deserves this
group's serious attention.  You've given me my homework assignment, I
can say...

Eliot

On 10/29/14, 9:37 PM, Murray S. Kucherawy wrote:
> On Tue, Oct 28, 2014 at 3:44 PM, Murray S. Kucherawy
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Since we're past the I-D deadline, the ISE or Pete will have to
>     approve its addition to the datatracker, so it will magically
>     appear at some point soon, and then move forward in the
>     publication process.
>
>

---

From: Douglas Otis <[email-masked]>
Date: Fri, 31 Oct 2014 16:45:34 -0700

Dear Murray,

Nice work as this is a great improvement.

The introduction properly states the function of DKIM or SPF is to detect and block unauthorized email.

Neither DKIM nor SPF determines:
1) valid RFC5322 structure
2) intended message recipient
3) sending domain
4) From header field content
5) Subject header field content

As such, using the terms authenticates and authentication should not be used when referring to DKIM or SPF results.  Nothing is being authenticated.  The real function is verification of an authorization.  It is dangerously misleading to overstate DMARC/SPF/DKIM mechanisms, especially since DMARC permits the weakest mechanism to be a basis for acceptance.
Leave the name of the document as is, in the hopes future mechanisms will enable an ability to actually authenticate domains.  Perhaps by using tokens similar to ApplePay or LoopPay. 

Section 2,

Was:
   However, there has been
   no single widely accepted or publicly available mechanism to
   communicate domain-specific message authentication policies, or to
   request reporting of authentication and disposition of received mail.

Should be:
   However, there has been
   no single widely accepted or publicly available mechanism to
   communicate domain-specific message verification policies, or to
   request reporting of verification and disposition of received mail.

Was:
   As a result, senders who have implemented email authentication have
   had difficulty determining how effective their authentication is, and
   use of authentication failures to filter mail has not been a success

Should be:
   As a result, senders implementing email authorization schemes have
   had difficulty determining how effective their authorization is, and
   use of authorization failures to filter mail has not been a success.

Section 2.2
 Was:
 o  authentication of entities other than domains, since DMARC is
    built upon SPF and DKIM which authenticate domains; and
Should be:
 o authorizations of entities other than domains, since DMARC is
   built upon SPF and DKIM which authorizes domains; and 

Section 3:
Was:
      Authenticated Identifiers:  Domain-level identifiers that are
      established using authentication technologies are referred to as
      "Authenticated Identifiers".  See Section 3.1.1 for details about
      the supported mechanisms.
Should be:
      Authorized Identifiers:  Domain-level identifiers that are
      established using authorization technologies are referred to as
      "Authorized Identifiers".  See Section 3.1.1 for details about
      the supported mechanisms.
Was:
3.1.1.  Authentication Mechanisms
Should be:
3.1.1.  Authorization Mechanisms

Was:
o  [SPF], which authenticates the domain found in an [SMTP] MAIL
      command when it is the authorized domain.

Should be:
o  [SPF], which authorizes the domain found in an [SMTP] MAIL
      command.

Section 3.1.4
Was:
Each of the underlying authentication technologies
Should be:
Each of the underlying authorization technologies
Was:
3.1.4.2.  SPF-authenticated Identifiers
Should be:

3.1.4.2.  SPF-authorized Identifiers
Section 5

Was:
   A Domain Owner may find that although its messages pass a particular
   authentication scheme's checks, it wishes not to have Mail Receivers
 
Should be;
   A Domain Owner may find that although its messages pass a particular
   authorization scheme's checks, it wishes not to have Mail Receivers
 
Although DMARC requires subsequent format checks of the From header field, it does not do this with the Subject line which often permits injectable clickable URLs.
As was done with the DKIM deployment RFCs, the same has been done for DMARC. It seems neither DKIM nor DMARC follow the path of least astonishment.
If history is any sort of predictor, DMARC will be gamed whenever receivers follow the path of least resistance and trust the Authentication results contained within messages.
It seems unfortunate that Internet Identified Mail was not adopted because it passed the public key within the message which was seen as causing too much message overhead.  Now, rather than correcting the DKIM validation process, domains are now expected to list all the headers used twice in each and every message.  As such, it seems IIM would now have been the better choice.
It is very dangerous to over sell the function of SPF and DKIM.  Both of these mechanisms are experiencing increased exploitation in highly critical areas.  It is unfortunate it took until May of 2014 for a major provider to finally acknowledge the nature of these exploits, although they had been explained much earlier in appeals and magazine articles.
Unless DKIM is repaired, both the DKIM Deployment and DMARC BCPs drafts are sorely lacking much needed guidance.  Guidance many are likely to find astonishing. 
Regards,
Douglas Otis