dkim-ops
[Top] [All Lists]

Re: [dkim-ops] BCP for authorizing third-parties ([...] was subdomain vs. cousin domain)

2010-09-14 10:05:37
Brett,

IMV, the topic of DKIM DNS management or who is saying is really a 
moot point because at the end of the day, it goes back to your initial 
posting here:

      How does the general public get protected from potential
      PAYPAL abuse when using the public list servers promiscuously?

That has been the issue and basis for the philosophical differences 
regarding policy for a very long time.

This has all been researched, debated, etc.  See the Security Threats 
RFC 4686:

       http://tools.ietf.org/html/rfc4686

The problem is that even with all that, we had out of scope influences 
that watered down the security concerns, namely because the List 
Administators wanted unrestricted DKIM resigning capabilities.  But 
since MLM is a natural breaker of integrity, some wanted their legacy 
software to continue working as is.  I still don't understand why one 
would consider DKIM for a MLM and not filter the restricted policy mail.

I'm afraid there is nothing you could do to protect your consideration 
of using a domain (low or high) outside a direct 1 to 1 mail transaction.

At best today, you can do:

    - Declare a "My Mail is always sign", with the reduced version of
      SSP called ADSP, that appears to be "DKIM=ALL"

    - Inform, suggest (mandate?) to your employees that with the
      new domains specially for employee usage outside the corporation
      that they only permitted to use it on KNOWN LIST SERVERS with
      DKIM signing support.

      Note: It might be useful for an advertisement of what a list
      server is capable of to first time subscribers

With this, what do you protect against?  At best:

    - Legacy Bad Guys who don't sign
    - Bad Guys using broken DKIM-Signature headers.

You won't be protected against:

    - DKIM Adapted Bad Guys signing as a 3rd party with valid signatures.

Thats it! Thats the best we can do expect at deterministic level. 
After that it is indeterminate environment which the wide spread of 
reputation people are trying to address.

    - Hope that the majority of the end users seeing paypal submitted
      list distributed mail are hitting receivers that are registered
      subscribers of reputation vendors (Batteries required syndrome).

Thats it!

No gathered statistics data will fundamentally change this long 
understood issue.  The data will most likely prove the above which 
doesn't regard proof.

On another related note:

We long understood that a centralized repository or server for 
reputation and/or certification would be ideal where everyone would be 
able to use as a single source lookup system.  But no one likes a "one 
vendor" to have this control.  Yet, there are vendors that offer a 
free API or method for verifiers.

Maybe that is what is needed is a standard for a "reputation lookup.'

Crocker, Otis, Leslie drafted the CSV-CSA proposal which is at the 
SMTP level.

    http://tools.ietf.org/html/draft-crocker-csv-csa-00

It was the first time that a "reputation" model was introduced for 
standard mail (during the MARID working group discussions, where 
SPF/SenderID was worked out as well for RFC draft standards) .

But it still had the "one vendor" and "batteries required" issue which 
no one really wanted (at the time) for a wide open standard across the 
network.  I always thought CSV-CSA was a good idea and eventually 
would be useful, but it wasn't ready for prime time.

Finally, maybe it is at this point it (the idea) is ready for prime 
time, but we don't have a reputation standard for DKIM which is a RFC 
5322 technology (not RFC 5321 level technology).

Suggestions were made (by me and Otis) where somehow we can pass the 
5322.From domain to the CSV/CSA layer like we wanted that for 
Sender-ID at the time discussed for MARID, and also useful for 
reputation services to offer a POLICY as part of their attributes for 
a domain records:

       [X] This domain requires mail to be signed.

That way, when an SMTP receiver does CSV/CSA, it can get the bits to:

   - Use it for Sender-ID at SMTP level
   - At the payload DATA level for DKIM Policy

But again, this requires batteries and its not a self-asserting policy 
design which would be ideal to cover the receivers that don't have 
batteries or the same batteries others are using to get that "Policy 
Bit" from the domain reputation/certification record.

As you can see, it all boils down to how can a domain, like a paypal, 
can make policy visible, practically, feasibly and scales in a way 
that doesn't hurt the DNS network.

We all have different ideas, some base of their current operations, 
some based on making a profit, some based trying to do it in a way 
that fits the current framework, some that want to make simple by 
SIGNING first and then figure it all out later.

That latter is simple and great for pure DKIM adoption, but its can be 
also  dangerous to create a new relaxed environment where it might be 
too late to protect DKIM signatures deterministically.  I don't feel 
we are there yet but it ain't going to happen until the concept of 
POLICY is better accepted especially by the reputation advocates.

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

McDowell, Brett wrote:
Here is why a paper should be written (BCP or not, IETF or not)..

On Sep 13, 2010, at 6:08 PM, J.D. Falk wrote:
They say the former scenario where ESPs sign with their own domains is still 
more common, because in general ESPs are more authentication-savvy than 
their clients tend to be.  

Ah, a deployment decision driven primarily by ignorance... that's an 
opportunity for us to educate.

The ESP domain wasn't chosen because anyone thinks it's a better practice, 
however.  

Ah, even worse, a deployment decision that is not even considered a better 
decision, driven by ignorance.

It's because otherwise, they'd be sending unauthenticated mail

So these less sophisticated senders aren't acting as if they are aware of 
their options and they are defaulting to a deployment configuration simply 
because they don't understand or are not prepared to deploy the alternative.

-- and many in the ESP world fear disastrous deliverability consequences if 
they aren't fully buzzword-compliant.

If the ESP's are worried about the sophistication of their clients then they 
may not be on the front lines trying to educate their clients of this key 
management alternative that more sophisticated senders are deploying.

So, I don't want to argue over whether or not this group (or IETF DKIM) 
should publish a BCP around this, I just want to find out sooner than later 
whether or not their is a rough consensus to pursue it here or not (then I'll 
know what I have to do next).

-- Brett
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops




_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops

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