Re: draft-schlitt-spf-classic-01.txt

On Fri, 2005-06-03 at 17:26 -0400, Alan DeKok wrote:
> Douglas Otis <[email protected]> wrote:
> > Going down the list of identifies available that could isolate security
> > and abuse issues to the accountable administrator, it would be:
> >   - IP Address
> >   - Authenticated HELO Name
> >   - Validated Signatures
> > 
> > You will notice that the mailbox-domain is not in this list.
> 
>  Not everyone agrees.
> 
>   I have vanity domains where I'm the only person with mailboxes at
> the domain.  I *am* the accountable administrator for that domain, and
> I would like to be able to state so.  I would like to be able to say
> publicly that any message not from me, using mailboxes at my domain,
> is forged.
> 
>   Some proposals allow me to do that.  The original purpose behind RMX
> was exactly that: Hadmut had a vanity domain, and couldn't stop people
> from forging messages using that name.  Hadmut was also very clear
> that not everyone would want to use RMX, but the people who would use
> it could protect themselves.
> 
>   The response then, as now, is that there is absolute opposition to
> such proposals.  The requirement that we permit ".forward" style MTA's
> to use third-party domain names is a requirement that people like
> Hadmut and myself cannot prevent others from forging spam using our
> names.

Those accruing reputations based upon evidence of abuse, have no way to
know whether the message was carried over a shared MTA or not, and in
the case of SPF version 1, whether the sender expected the
bounce-address or the PRA be used as a basis for acceptance.  If SPF
were used just to reject messages from unauthorized servers, which is
rarely the case due to path registration problems, indeed there would be
far less risk involved when publishing SPF records.

While some domain owners may run their own MTA and permit just their
domain to utilize the MTAs that carry their outbound messages, this
would not represent a typical case.  The outright blocking of messages
from unauthorized servers is often not practical either.  There will
always be cases where email is lost or refused, when attempting to
create such strict path registrations.  Lost messages can be problematic
whether for financial institutions or large network providers.

Recipients are left using a filtering paradigm that attempts to
establish acceptance thresholds for the multiple levels of authorization
presented by SPF.  The additional lowered levels of authorization
attempt to convey the likelihood a sender conforms to path registration.
Of course, there is no way to accommodate any forwarding that may
process their message.

While not everyone may agree, strict server authorizations and exclusive
MTAs represent special cases.  Even these special cases offer little
benefit in terms of phishing prevention.  The recipients willing to
dredge through often extensive path registrations, would be hard pressed
to realize a benefit, when the majority of messages reference open-ended
records, and no reputation is accrued.  There is the danger.  With SPF,
corner cases will likely find themselves in the junk folder, and those
that permit exceptions with open-ended records, may also find their
reputation damaged.  Those that share an MTA may also find their
reputation damaged and should demand indemnification from their
provider.


> >   This mailbox-domain identity is passed from MTA to MTA, and is
> > unrelated to an accountable administrator.
> 
>   Ah, yes.  If we assume the current behavior is desired, then the
> conclusions are foregone.
> 
>   If, on the other had, we have the temerity to question the existing
> assumptions, then the conclusions are questionable, too.

When today's systems are able to digitally sign messages without
requiring additional hardware, and can do so in the time needed to
dredge through path registrations, you should question schemes that
require wrenching changes to decades old and highly pervasive
architectures.  With signatures, you do not need your email provider to
swear they make mailbox-domain restrictions.

Path registration and mailbox-domain restrictions create a very bad
premise for basing a new reputation scheme.  This premise suffers two
very serious flaws.  It often fails to identify the accountable
administrator, while at the same time expects the administrator to
impose additional expensive limitations on the use of mailbox-domains.
At least warn the domain owner to ensure domain restrictions are in
place by the provider before publishing SPF records.

 
> > SPF or Sender-ID also makes a false assumption that the MTA is not
> > shared, or that the MTA administrator ensures user/mailbox-domain
> > relationships are protected.
> 
>   SPF and related proposals allow the DNS administrator to claim that
> the MTA satisfies certain criteria.  But this benefit is being turned
> around, and claimed to be an accidental, and negative side-effect.

There is nothing provided by SPF that indicates whether 1 or 1000
domains use an MTA or whether any mailbox-domain was initially checked
for that matter.


> > I have yet to hear anyone caution domain-owners they should first become
> > indemnified in their provider's SLA, and be assured only their messages
> > are permitted to use their domain in the bounce-address
> 
>   For me, it isn't so much about permission as audit trail.  If I
> can't prove a particular message using a mailbox address is actually
> associated with that address, then I have no idea if the message is
> forged or not.  Signatures don't help, as anyone can create a
> certificate or key for any identity they want.

Either path registration or a key from DNS do not add any new identity
abstractions.  Not just anyone can create the path registration for the
domain.  Not just anyone can create a key for the domain.  Signatures,
unlike path registration, do not depend upon knowing beforehand the path
a message eventually takes, and hence will not break current email
architectures.

Unlike path registration, the private portion of the key is not exposed,
which provides the possibility for a stronger audit trail, than that
available with path registration.  The key itself could be used to sign
prior keys, as example.  Of course, this is similar to DNSsec.


>   What matters is the "web of trust", or the relationship.  Signatures
> *can* help if the certificate for "[email protected]" is signed by the
> key for "example.com", and the key for "example.com" is signed by a
> known CA.  In that case, the signatures are a means to an end, not a
> solution in themselves.  They make the relationship management easy
> and reliable, nothing more.

While a CA would offer improved security, as would DNSsec for that
matter, DKIM relies upon the security of DNS the same as SPF does.  I
attempted to illustrate how doing non-recursive key lookups could be
used to establish a key audit, as an interim solution for DNSsec.  I
doubt such scheme will be employed, unless some exploit makes such
auditing required.  I described it in the
draft-otis-mass-reputation-01.txt draft to improve the chances this
concept would be available if needed.

-Doug