ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Blocking improperly signed messages

2006-12-10 08:09:08

On Dec 9, 2006, at 8:05 PM, Hector Santos wrote:

Douglas Otis wrote:
On Dec 9, 2006, at 8:24 AM, Scott Kitterman wrote:
From a requirements perspective, I think providing policy for non- existent domains is explicitly NOT a requirement. For a domain to be covered by SSP, it MUST exist. I like Graham Murray's definition of exists.
An Address RR could be for anything. Blocking "improperly" signed messages would require discovery of a policy RR indicating exclusivity (all "From" headers are assured to be signed). The likely outcome of such an assertion is disabling use of mailing- lists.

First isn't that a contradiction? If a company invest in DKIM and prefers to use an exclusive policy for some of its high value domains, it would be highly probably that it be done on the basis to stop such public external usages. That would be one goal. Protection from unauthorized usage of their domains.

Note, this doesn't stop a company from using using a Mailing List Server for original signed distribution. But if you are talking about open ended mailing list such as this one, it would be an contradiction to define a exclusive policy and continue to behave in this open "laissez faire" promiscuous manner.

Second, this issue of MAILING LIST SERVER (MLS) really has nothing to do with SSP but with DKIM-BASE mail integrity issues. Thats the problem with a MLS, not SSP. SSP is really the easy part when it comes to a MLS. You could throw SSP away and you STILL have the mailing list DKIM-BASE mail integrity problems.

That's not the case.

No mailing list (or other) corruption of an email in transit can do anything worse than change the delivery of a legitimate, DKIM-signed email into the delivery of a legitimate non-DKIM-signed email.

It's not until you hang the SSP bag on the side that this has any negative impact on legitimate email usage.

The problem is the idea of MLS resigning in order to correct the DKIM transaction of a broken original signature. This is where SSP plays a role in defining the 3rd party authorization, otherwise, SANS SSP, you have a major threat with bad actors using a MAILING LIST to mask a broken original signature with a resigning.

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

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