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

[Scott Kitterman <[e-mail]>]

It's not news that there's a risk for SPF associated with shared IP addresses.  
That's why it's in RFC 7208 (11.4) and was in RFC 4408 similarly before.

I understand your view and agree on the problem.  I also sympathize with the 
need to technically address conditions as they exist in operations.  I'm not 
convinced that we should bake the solutions into protocol, however.

As I've said before, I think this is primarily and economics/incentives 
problem, not a technical problem.  If you increase the incentives for third 
party providers to support DKIM in place of SPF, I don't think you've actually 
solved anything.

As fas as I've seen, the low cost (for a third party to sign using their 
customer's domain name) approach is for the third party provider to publish 
DKIM key records based on their own private keys and then tell their customer 
to put a CNAME in their DNS that points to it.  In the case of a shared 
server, the third party provider then needs to keep track of which customer is 
authorized to sign for which d= domain, but they can use their own keys/
infrastructure for doing so.

The internal management function of keeping track of which customers can use 
which signing domains is essentially the same as the internal management 
function of keeping track of which customers can use which Mail From addresses 
with SPF.

My speculation (and it is that), is that the most cost sensitive third party 
providers currently use SPF only and are less likely to keep effective control 
of which customer can send from which identity precisely because it's less 
expensive.  If you change the deployment incentives so that DKIM is now more 
necessary for some of their customers, they'll no doubt deploy it, but without 
better internal controls, you'll end up with the same problems with these 
providers expressed through a different technology.

Scott K

On Tuesday, July 11, 2023 8:49:28 PM EDT Wei Chuang wrote:
> The data we presented June 20th (archive
> <https://mailarchive.ietf.org/arch/msg/dmarc/KeGbMfX91WJk_aziKsrRfI6AYkI/>)
> also suggests that it is premature to drop SPF from DMARC.  However I
> differ in believing that we should accept the spoofing risk demonstrated
> recently via SPF, and that we shouldn't strive to reduce it by making
> improvements to DMARC and possibly SPF.  One approach is to enable
> different senders to distinguish their differing levels of risk and
> infrastructure by letting them specify an "auth=" flag proposed on the 20th
> <https://mailarchive.ietf.org/arch/msg/dmarc/KeGbMfX91WJk_aziKsrRfI6AYkI/>.
> For example a mom-and-pop sender on their own infrastructure with their own
> IPs will have a different profile than a risky, enterprise sender on shared
> IPs.  The former would be reasonably safe using SPF and would benefit most
> from using it.  The latter should use DKIM authentication only due to the
> risk of SPF upgrade spoofing and the phishing exposure.  I describe some
> additional ideas about how to use "auth=" flag with different risk and
> infrastructure stratification on the DKIM list on July 3rd (archive
> <https://mailarchive.ietf.org/arch/msg/ietf-dkim/6ms55apP0RtLzr34CCgjWRYkVsA
> /> ).
> 
> And FWIW I don't think mom-and-pop senders will find it that hard to adopt
> DKIM if sufficiently motivated.  For example for BIMI on Gmail, we now
> require DKIM-only authentication.  Indeed a new BIMI sender that I perceive
> to be running literally a "mom-and-pop" produce shop was using SPF
> authentication and was confused as to why their logo wasn't showing.  After
> explaining the requirement they were able to move to DKIM authentication in
> one day.  Yes, it did take explaining twice what was happening, but they
> were able to deploy DKIM on their own and got their logo to show up.
> 
> Also can we do more to harden SPF?  The SPF upgrade attacks needs three
> things:
> 
>    - IPs shared by multiple sending domains
>    - Some sender uses those IPs that permits spam and phish traffic
>    - Those multiple sending domains have SPF policies that include those IPs
> 
> Perhaps one way to harden to SPF for DMARC is to detect if the IPs are
> shared.  The authenticator in addition to regular to SPF validation, might
> be able to use reverse PTR lookup and match the SPF record domain name (or
> match some subset like the org domain) to forward validate.  Only one
> domain can claim ownership for the IPs and be allowed to SPF authenticate
> for DMARC.
> 
> -Wei
> 
> On Mon, Jul 10, 2023 at 5:38 PM Scott Kitterman <[e-mail]>
> 
> wrote:
> > 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-identi
> > fication/
> > 
> > 
> > _______________________________________________
> > dmarc mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dmarc