ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Delegating responsibility: a make vs. buy designdecision

2006-08-17 17:28:45
Dave, this is not off-list, but I would say its off-base. :-)

All you guys are showing is how Relaxed Policies can be abused.  No more, no
less.  Most everyone understood this and thus why SSP strong policies are
necessary to be part of the total package.

You guys are stuck on allowing *anyone*, any middle ware software signing
mail along the transaction path to be OK!

If the DOMAIN is going to allow his ISP to sign mail on his behalf, meaning
the ISP has full control of the DOMAINS private key, then the DOMAIN should
have a policy that says so, and the ISP should know that blindly SIGNING
mail can create a huge problem for the DOMAIN.

Remember, the DKIM-BASE specifically says:

   The ultimate goal of this framework is to permit a signing
   domain to assert responsibility for a message, thus protecting
   message signer identity and the integrity of the messages
   they convey while retaining the functionality of Internet
   email as it is known today.

And in addition it says:

   INFORMATIVE NOTE:  Signing modules may be incorporated into any
   portion of the mail system as deemed appropriate, including an
   MUA, a SUBMISSION server, or an MTA.  Wherever implemented,
   signers should beware of signing (and thereby asserting
   responsibility for) messages that may be problematic.  In
   particular, within a trusted enclave the signing address might be
   derived from the header according to local policy; SUBMISSION
   servers might only sign messages from users that are properly
   authenticated and authorized.

So if the ISP or any middle ware along the path is going to blindly sign
mail, it is putting a responsibility on the DOMAIN that probably he didn't
want or atleast in the form he did not expect.   If you are going to allow
this, then the DKIM-BASE mandates and semantics regarding "responsibility"
and "message signer" and "signing domains" must change.  It would NO LONGER
protecting the FROM: address.  He is NOT in the picture any more because
ANYONE can signed with the NO-SSP proponents.

In any case, even in this scenario, the verifier is not going to really care
who SIGNS it. It is the about very basic LOGIC:

   o  Does the domain ever distribute mail?
   o  Do you expect the mail to be unsigned?
   o  Do you expect to sign all mail?
   o  Is your domain the exclusive signer?
   o  Are 3rd party signers or signatures allowed?
   o  Are 3rd party signers allowed to strip your original signatures?

Its very simple.   The main threats are the above.

Finally, think about what you are creating if there is NO SSP possible for
the domain to declare.  Verifiers and MUAs or presenters can only assert one
thing:

    "This message was verified as being safetly delivered from
     the signing domain - ANYONE.COM."

[Note: yet at the same time, you want is to ignore any other
multi-signatture failure along the path.]

In this case, there can not be ANY association with the FROM: address
because it will create a FALSE illustion that the message is indeed
originating
and authored by the FROM: original author and that it was deemed "safe"
because some middle-ware, anyone.com, signed it.

In summary, if you have relaxed policies or no policies at all, a DKIM-BASE
only environment is going to create major problems for veriifiers and
ultimately for domains who may not even expected it in the first place!!

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





----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: "ietf-dkim" <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Thursday, August 17, 2006 7:11 PM
Subject: Re: [ietf-dkim] Delegating responsibility: a make vs. buy
designdecision


offlist

Wietse Venema wrote:
     If a signature uses a domain related to the author's domain, then
we have
no SSP issue.  The author's domain is used for assessment.  No SSP
query need be
made.

[Plus a straightforward DNS-based delegation mechanism so that the
author's ISP can use a UNIQUE signing domain that relates directly
to the author's domain]

hence the examble's using isp.author.com, yes?


I like this. This is very close to what I want: signed mail that
speaks for itself, whether it's first-party or third-party signed.
No batteries required.

and just to make sure *I* understand what you mean:  mail signed by the
author,
or mail signed by an operator?

d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html



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

<Prev in Thread] Current Thread [Next in Thread>