Re: [dmarc-ietf] Suggestion: can we test DEMARC deployment with a mailing list?

[Hector Santos <[e-mail]>]

On 5/6/2014 11:59 AM, Dave Crocker wrote:
> On 5/5/2014 5:37 PM, Fred Baker (fred) wrote:

>       1.  DKIM and SPF have been fielded for perhaps 12 years.  DKIM in
> its original-but-similar form, DomainKeys, and then its initial
> 'consortium' form, preceded the 2006 published DKIM RFC by several
> years.  SPF appeared around that time too.  So the reference to 6 years
> of operational experience is really on the very low side.

9+ years was the reference, not 6.  Yes, the original DKIM+POLICY model
was conceived from DomainKeys with its built-in strict policy "o=-" 
option. DKIM's policy features was called SSP which included support 
for allowing resigners.  The problem was how to large scale authorized 
resigners.

>
>       2.  Use of DKIM and SPF is reasonably well understood and does not
> cause interesting email operations problems.  I'm starting to hear some
> unfortunate stories about DKIM signature breakage in scenarios that I'd
> have hope would not have it, but the breakage of the signature is not
> breaking legitimate email scenarios.

SPF is a domain policy protocol.  DKIM lacks one. DKIM is totally 
useless and unsecured without a policy layer. The DKIM Threat Analysis 
RFC4686 touches base with this. https://tools.ietf.org/html/rfc4686

>       3.  DMARC's functions and limitations have been reasonably well
> understood since it's inception.  It works comfortably in specific
> scenarios and causes problems in others.  Again, there are no surprises
> about these now.  They've been clearly understood by those working on
> the spec.

But the problem is that the DKIM resigners didn't support it nor its 
predecessor ADSP for any use case, large or small.

>       4.  SPF actually has the potential for causing similar operational
> problems.  It has a strict mode that will cause receiver-side rejections
> if honored, and they will occur for any multi-hop sequence.  In the case
> of SPF, multi-hop means /any/ sequence that produces a new client smtp
> IP address, presented to the evaluating receiver.  In the case of DMARC,
> given the use of DKIM, the problem is multi-hop for scenarios that break
> DKIM signatures.
>
>       5.  The reason SPF's strict mode hasn't been problematic is that
> virtually no one uses it.

No, it wasn't a problem because the "YAHOOs" didn't do a -ALL policy 
or those domains that did not have a handle on their network of mail 
senders.  Those that did use -ALL and there are thousands of domains 
who are, including ietf.org with its string -ALL SPF policy, had very 
little problems with them.

   v=spf1 ip4:12.22.58.0/24 ip6:2001:1890:123a::/56
          ip4:64.170.98.0/24 ip6:2001:1890:126c::/56
          ip4:4.31.198.32/27 ip6:2001:1900:3001:0011::0/64
          ip4:209.208.19.192/27 ip6:2607:f170:8000:1500::0/64
          ip4:72.167.123.204
          -all

But in principle, whether it was YAHOO or another domain, the SPF 
network of SPF receivers did support the -ALL rejection semantics. 
That wasn't the case with ADSP Discardable and DMARC p=reject until 
now with the switch turned on.

> So what's different now is not technical, its operations policy.  A
> couple of large providers chose to apply DMARC to scenarios known to
> cause problems for some of their users and groups their users work with.

Dave, its a technical problem because the DKIM-WG intentionally 
deemphasized an author domain policy lookup layer seeking to replace 
it with a 3rd party signer domain trust/reputation lookup service 
model.  The latter hasn't materialized so DKIM was left unprotected 
without the author domain policy layer.  The removal of policy has 
caused interop problems.

The goal now is to give DMARC 3rd party semantics and support within 
the DKIM framework where the resigners can coexist cooperatively.

-- 
HLS