ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] NEW ISSUE: Security Threat: Unexpected Third PartySenders

2008-02-13 03:10:38
John Levine wrote:
That's not quite what we had in mind.  As I see it, 3rd party signing
is only acceptable when the domain owner wants to permit it --

It would be possible to design a system in which domain A says that it
endorses domain B's signature on mail with an author address at A, but
if you dig through the list archives, you'll find that we rejected
that expansion of SSP quite a while ago.

hmmmmm, I don't believe that is true John. I think you are reading your own adaptation where stripping down SSP-01, removing such Verifier Accepable 3rd party Signature semantics from the spec, relabeling it ASP does not make it "while ago". I think I am fairly certain ASP is only week or so old.

Anyway, while there were various proposals and ideas not everyone was tickled pink with, it was quite clear the concept was feasible enough to get written in stone in SSP-01:

2.11.  Verifier Acceptable Third-Party Signature

   A Verifier Acceptable Third-Party Signature is a Third-Party
   Signature that the Verifier is willing to accept as meaningful for
   the message under consideration.  The Verifier may use any criteria
   it deems appropriate for making this determination.

3.  Operation Overview

   ..

   2.  All messages from this domain are signed.  Messages containing a
       Verifier Acceptable Third-Party Signature MUST NOT be considered
       Suspicious.

          NON-NORMATIVE RATIONALE:  Third-party signatures, since they
          can potentially represent any domain, are considered more
          likely to be abused by attackers seeking to spoof a specific
          address.  It may therefore be desirable for verifiers to apply
          other criteria outside the scope of this specification in
          deciding to accept a given third-party signature.  For
          example, a list of known mailing list domains used by
          addresses served by the verifier might be specifically
          considered acceptable third-party signers.

And in RFC 5016, it goes as far as using suggesting DNS CNAME techniques:

   6.  Because DKIM uses DNS to store selectors, there is always the
       ability for a domain holder to delegate all or parts of the
       _domainkey subdomain to an affiliated party of the domain
       holder's choosing.  That is, the domain holder may set an NS
       record for _domainkey.example.com to delegate to an email
       provider who manages the entire namespace.  There is also the
       ability for the domain holder to partition its namespace into
       subdomains to further constrain third parties.  For example, a
       domain holder could delegate only _domainkey.benefits.example.com
       to a third party to constrain the third party to only be able to
       produce valid signatures in the benefits.example.com subdomain.
       Last, a domain holder can even use CNAME's to delegate individual
       leaf nodes.  Given the above considerations, SSP need not invent
       a different means of allowing affiliated parties to sign on a
       domain's behalf at this time.



--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

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

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