[dmarc-ietf] Protocols All The Way Down (long - sorry)

[Scott Kitterman <[e-mail]>]

I've been thinking about the thread on ditching SPF relative to DMARC.

DMARC is built on other protocols.  Piles of them.

DMARC is built most directly on DNS, DKIM, and SPF.  It is also built on SMTP 
and Email.  DKIM and SPF are also built on DNS and SMTP (SPF) or Email (DKIM).  
These protocols are built on others.  All of them have flaws and limitations.

As an example, although each of the three top level protocols in this 
particular stack depend on data from DNS being reliable, they merely counsel 
caution about DNS spoofing, they don't mandate DNSSEC.  Note that other 
protocols have different choices in this regard (e.g. DANE).

We accept the risk of DNS spoofing associated with non-DNSSEC secured DNS 
because the view is that the benefit to deployability of SPF, DKIM, and DMARC 
is sufficient to offset the risks.

What are the risks?  Since DNS spoofing is not particularly easy since Dan 
Kaminsky got everyone to implement source port randomization [1].  I think 
it's reasonable to assume if an actor is going to the trouble to spoff SPF/
DKIM/DMARC records, then it's to try and get a 'bad' message to appear 
authentic.  I'm not aware of this being a significant problem (probably since 
there are easier ways to do it), so I think the design decision to not limit 
these protols to DNSSEC protected domains is a reasonable one.

Similarly, SPF pass results can be leveraged to a DMARC a DMARC pass result if 
an actor can manage to get a third party provider to accept mail to be sent 
with the victim domain's mail from when that domain has listed that third 
party as a source of authorized mail.  RFC 7208 warns about this risk {2}.

DKIM has different risks.  The cryptographic mechanism used by DKIM is meant to 
provide strong, but limited duration assurance that an email was sent through 
a mail server authorized to do so and additionally that it has not been 
modified in certain ways since.  This has not always worked out well [3].  It 
only took the IETF six years to address the issue [4].  Additionally, for some 
types of senders, they can be vulnerable to replay if they sign on 'bad' 
message in error.  This is an issue that was identified during DKIM's 
development and warned about in the protocol documentation [5].

This might all seem terrible, but it's really not.  If you look that the goals 
of DMARC (current draft section 2.1), they are modest.  Specific to this 
particular question:

   *  Allow Domain Owners and PSOs to assert their desired message
      handling for authentication failures for messages purporting to
      have authorship within the domain.

   *  Reduce the amount of successfully delivered spoofed emails.

The risks associated with all the above issues are that there are cases where 
'bad' messages pass DMARC and so the domain owner/PSO policy is not applied.  
Given that none of these protocols are perfect (and the risks extend much 
further than these I've highlighted), there are always going to be messages 
that get marked DMARC pass that are 'bad'.  Fundamentally 'good' and 'bad' 
aren't fully reducible to a protocol and the gaps between the protocol and 
human judgement will always exist.

Any message that passes DMARC should still be sugject to the normal spam/ 
phising prevent processing done by receivers.  Just because you got an email 
from bigbank.example which passed DMARC, doesn't mean that it might not have 
been sent through a compromised desktop in bigbank.example's office that has the 
least professionally run information secuirty opreation.

DMARC is going to have false positives and false negatives and those need to 
be considered by implementers when assessing how to use DMARC.  The 'problem' 
with DMARC (including the 'problem' with SPF in DMARC) only arises when DMARC 
results are used in ways that were never intended.  By design and based on the 
goals of DMARC, a DMARC pass result doesn't carry any guarantee that any 
particular email was in fact sent legitimately by the organization that 
claimed to send it, but unfortunately, people are assuming it does [6].

As I've said before, I don't think dropping SPF from DMARC is a good idea and 
I don't think it will usefully solve the problem that proponents of dropping 
think it will solve.  I do think we need to do something in the draft to 
address the overall question of the reliability of the DMARC assertion that a 
particular message is authorized/has been authenticated.

The think that the current security considerations are insufficient and we can 
address these concerns by expanding on them.  Currently, the DMARCbis Security 
Considerations start with:

> 11.1.  Authentication Methods
> 
>    Security considerations from the authentication methods used by DMARC
>    are incorporated here by reference.

I would assess that as necessary, but not sufficient.  Here's my proposal for 
expanding 11.1:


11.1.  Authentication Methods

   Security considerations from the authentication methods used by DMARC
   are incorporated here by reference.  See [RFC6376 Section 8] and [RFC 7208,
   Section 11].  Failures in the underlying methods can result in incorrect
   DMARC results.  The impact of such incorrect results is that sender's DMARC
   policy would not be applied in some cases where that is desirable.  Since
   DMARC itself associates no positive attribute with a DMARC pass result, the
   impact of these cases is generally minor.  Any domain owner that intends to
   make use of positive DMARC results as an overall indication of domain
   reputation will need to carefully assess the impacts of these risks to such
   an assertion.

Something like that.  I think this topic should be on the meeting agenda too.

Scott K


[1] https://lwn.net/Articles/289138/
[2] https://datatracker.ietf.org/doc/html/rfc7208#section-11.4
[3] https://www.wired.com/2012/10/dkim-vulnerability-widespread/
[4] https://datatracker.ietf.org/doc/html/rfc8301
[5] https://datatracker.ietf.org/doc/html/rfc6376#section-8.6
[6] https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/