spf-discuss
[Top] [All Lists]

RE: [spf-discuss] Re: SPF TXT Questions re Effectiveness

2006-12-02 21:32:03
Julian Mehnle wrote on Saturday, December 02, 2006 7:50 PM -0600:

Seth Goodman wrote:
From the standpoint of the recipient, you can determine that a PGP
key belongs to an individual to a degree of certainty that you
understand. You know the trust relationship in detail and make of
it what you will. It is much more tenuous for designated hosts.  A
recipient has no way to evaluate the extent to which a host is
secure and the strength of the measures used to discourage forgery.
Neither does a recipient have any way to evaluate how many machines
have submission rights to that host and their level of security.

The same does apply to the security of a PGP key.  How do you know
whether the private key is stored protected with a passphrase or not?
How do you know whether the private key is not readable for all users
on the system where it is stored?  How do you know if the private key
isn't deliberately being shared among a group (of unknown size) of
users?  How do you know that PGP private keys aren't stored on a
central server of the sender organization and all messages sent are
being signed on that central server?

No recipient knows whether a signer has any of those problems.
Recipients do understand that if the sender cares at all to secure
their secret key, it is very easy to avoid all of those problems.
Since the sender bothered to ask others to sign their public key, it
does not require a lot of trust to believe that they will secure their
secret key.  In contrast, it requires a lot more trust to believe that
a given mail host is secure, does not permit cross customer forgeries,
acts rapidly on forgeries when discovered and has secured all of the
networked machines that have mail submission rights.


All a recipient can say is that the return-path domain is verified
according to the senders wishes.

... according to the sender's wishes, exactly.  Here, the sender is
the authority with regard to what constitutes an acceptable assertion.
That is a general concept of authentication, not specific to any
single method.

Senders can tell you the verification algorithm, but they can't tell
you how much to trust the result.  You know when the sender trusts the
result enough for you to reject on FAIL.  Whether the recipient
considers it trusted enough to proceed on PASS is a separate question
that SPF can't answer.

Once verified, digital signatures are trusted according to the wishes
of the recipient, and the sender doesn't know the recipient's criteria.
The first step is similar for both SPF and PK crypto:  you use
published information from the sender to generate a validation result
for a given message.  With PK crypto, you then determine your overall
trust in a positive result based on your trust relationships with the
co-signers of the public key and their trust relationships to the
signer.  How much you trust each co-signer, how you handle degrees of
separation and how much total trust you require is entirely up to each
recipient.  PK crypto systems provide the hooks for recipients to
determine their overall trust in the signer's assertion.

The real question is whether you can trust the validation result enough
to use it for the intended purpose.  If you want to determine the
authenticity of the return-path domain based on sending MTA IP/HELO
name, with the purpose of rejecting return-path forgeries, then I think
SPF is good enough.  It's not a digital signature, and you don't need
one for this purpose.


The grade of security of any assertion method only depends on the
odds of it being plausibly reproduced against the will of the
authority, not on some inherent magical properties.

I agree.  Saying you possess the secret key corresponding to a
public key that was signed by numerous individuals a recipient
trusts after verification in person is a much stronger assertion
than saying you designate a given host as permitted to send mail on
behalf of your domain.

I agree that it is generally stronger.  But who can say that the one
is generally "sufficient" for a given purpose while the other isn't?

I'd answer that I think SPF is good enough for rejecting return-path
forgeries based on sender criteria and enabling the recipient to use
return-path domain reputation systems.  A recipient has no reason to
trust an unknown sender, so they can't take the sender's word for what
is legitimate (unless you define legitimate as anything that generates
SPF PASS).  SPF doesn't include the reputation system required to trust
SPF PASS.  However, a PASS does permit the recipient to apply separate
domain-based reputation.


In a strong system, the prover makes an assertion that he is
actually in a position to prove.

How would I prove to you that I haven't given my PGP private key away
to others?  Or, more realistically put, how would I prove to you that
my key hasn't been stolen?

You can't prove that, but you ask me to trust it is true.  That does
not require very much trust, so I will probably believe you.


A person can prove his identity to a high degree of certainty to
others who do not possess special skills,

Well, yeah, that's the theory. :-)

but proving that a given mail host and the network behind it are
secure is pretty difficult.

True.

That's why the SPF assertion is relatively weak compared to the PGP
assertion.  However they are both good enough for their intended
purposes.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFci1YwL7PKlBZWjsRAtIkAJsE7DdLB0MfwMD3epB54OqTIEK/vACgvRCG
aKzbx0SIlD/E24M5Xwiffbk= =RRfI
-----END PGP SIGNATURE-----

You expect me to trust that?

--
Seth Goodman

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to http://v2.listbox.com/member/?list_id=735