ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] A few SSP axioms

2006-08-02 07:15:48

----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>


Hector,

Yet another claim of utility with no demonstration!

Are we referring to a "useful scenario?"  Does it matter if is past or
preesent?

As far as I am concern until all this is proven, it is all claims

What seens to be the most common difference here is one side says that
secondary signatures causes no harm.  Isn't that a claim?  Where is the
demostration that it does not?  The other side says "We don't expect anyone
to message with mail."  You're asking for demo as to why it useful.

I just having a hard time understanding what is fundamental difference.

Lets use John's example:

   My wife gets all her mail relayed through an alumni
   account at cornell, and at some point Cornell will sign
   the mail they relay as it passes through.  So we're
   going to accept lots of mail with Cornell signatures,
   and if you insist that we not do so, all you will
   accomplish is to persuade us that that you are being silly.
   If a message has your signature, it's your message.  If it
   also has a hundred other signatures, it's still your message.

Is this is demonstration or a claim?  Until he can proven that there is no
harm in this process, it is claim.  There is no demontration that there is
no harm here.

Now, the point i am saying is that is more risky. How much? Don't know, but
certainly more than an expectation not having multiple signatures.  So if a
domain does not want them, why the push back to avoid this policy?  I don't
get it.

I do agree that we have to cater for an imperfect world,
but you have yet to demonstrate a case where that makes
it bad to add signatures to a signed message (from a
bank or whatever).

I believe I have Stephen.  I think its just a matter of difference of
opinion in usefulness.

I didn't say it makes it bad, what I said, that it may be desirable by a
domain, including myself as a developer and consumer of such mail goods, to
have 100% exclusivity in my mail transactions.

Is the disagreement is that this desirability is unrealistic?

Why don't you(*) just show me the benefit?

In all honesty, and hang in there with me because there is certainly people
who agree with this because for some odd reasons choose to only say it to
me, and not in public, we don't understand the "push back" or what is so
hard to grasp about a domain wanting to have full control of his domain and
his mail is moving thru the system.

There is a very fundamental practice in SMTP operations to minimize any mail
tampering. There is very limit exceptions to this and you can count them in
your hand where are current useful applications that mail break mail
integrity (i.e. List Server).

Digital signatures has inherent understanding of integrity. So if a domain
"chooses" to prepare his transactions with with a desire that the mail is
not touched or worked on, why we would be so resistence to this?

Is it because we don't believe it will work?  I mean, if this is the reason,
then that means exclusive policies fails on its technical merits and if that
is the case, then we kill it and move on.

But if its not a concept that fails on its technical merits, there are a few
of us that believe exclusive policies "can" be very useful.

If its because you think this should be useful but aren't
sure exactly how, then that's fine, just say so and the WG
can take that into account when evaluating which requirements to
adopt.

I don't have a problem understanding its usefulness, Stephen. Not at all. In
fact, I stated since day one, since the old list, how exclusive signing
options is very restrictive and deemed highly useful for domains what
require that level of consideration.

If I posted DSAP description for exclusive policy, is this still a claim or
demonstation? (Note: I did not write this section. 3rd party input)

5.5.  Only Original Party Signature Expected

   *Policy: op=always; 3p=never;*

   If this policy is defined, then a DKIM signature MUST exist and it
   must be signed by the original domain only.  If no signature is found
   or a 3rd party signature is found, the verifier SHOULD honor the
   domain policy request to negatively classify the message.

   This policy is considered to be an exclusive signing practice by the
   original domain only and is expected to be used by organizations that
   never send any email to mail lists or through 3rd parties and always
   expect to communicate directly with recipient.  Such organizations
   are those providing data of very sensitive nature (such as personal
   financial information) and using strong internal security policies.
   These organizations are often highly concerned about inappropriate
   and fraudulent uses of their domain (such as cases of "phishing") and
   want to make sure that only emails directly from their system are
   accepted as valid by recipient.

   Here is an example of such policy record used by an imaginary Bank
   with domain bank.example.  Please note tags are separate per line for
   illustrative purposes only:

   _dsap._domainkey.bank.example.  IN TXT
         "v=dsap1.0; a=rsa-sha256; op=always; 3p=never;
          n=We only send DKIM signed email, do not trust anything else
            such as notices allegedly from 
security(_at_)bank(_dot_)example(_dot_) Please
            report all such abuse to;
          r=phishing-reports(_at_)bank(_dot_)example;"


   Note: The above comment in "n" tag is very long and given only to
   help illustrate this example.  Whenever possible shorter text should
   be used in DSAP records.

Again, the technology doesn't exist yet. It is still vaporware. So I can
image it being labeled as a claim of usefulness with no real demonstration
of usefulness.  All semantics, but it isn't very hard for some of us to see
the real practical usefulness of this strong policy. I didn't write the
above.

PS: Maybe it would be a good idea for the WG to officially announce the
availability of the DSAP I-D draft.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com





_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html