Hector, thank you for the thoughtful post and background. Since "reputation services" have the use cases most under-supported per your analysis by today's technology choices, I suggest you re-post this (or something like it) on the ietf-domainrep list for discussion.
-- Brett On Sep 14, 2010, at 11:00 AM, Hector Santos wrote: > 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 >> [email protected] >> http://mipassoc.org/mailman/listinfo/dkim-ops >> >> > > _______________________________________________ dkim-ops mailing list [email protected] http://mipassoc.org/mailman/listinfo/dkim-ops
