[ietf-dkim] Re: making SSP useless in one short step
dhc at dcrocker.net
Wed Dec 5 11:08:34 PST 2007
Michael Thomas wrote:
> [Who is apps-review, and why are they rejecting messages? If this is
> intended as an apps area review where only Dave gets to post, that's a
Apps review is an existing mechanism. I participate in it. Others
participate in it. I used it exactly the same way I have used it for previous
reviews I have done, except cc'ing the wg rather than the authors. I didn't
create the mechanism. I used it specifically because it is an established
That said, I think the list I posted to is used to record the review, rather
than for on-going discussion, so I have removed it from the cc list.
If you dislike the mechanism, feel free to direct comments about it to the
Apps area directors.
>> Again: SSP is now not restricted to unsigned messages. It applies also
>> to a potentially very large class of signed messages. In effect, SSP now
>> appears to attempting to emulate SPF strictures of correlation among
>> identity fields.
> If SSP is going to have any utility whatsoever, it cannot be defeated by
> the mere act of signing a message from any random domain.
There is quite a lot implied by saying "defeated".
Perhaps you could explain the operational, threat and protection models that
substantiates your assessment. I am pretty sure it has not been clearly
documented. It seems pretty clear to me that the models require a homogeneous
and reliable end-to-end service, with considerable cooperation among all
senders and receivers, with no signature breakage.
In any event, it is worth commenting on the reasons that the reputation of the
random domain that does sign are rendered irrelevant. (I asked this before
but have not seen a response.)
> would be completely and utterly useless, and a complete joke to create such
> a specification. When a domain says that it signs all of its mail, it
> means just that. It doesn't mean that maybe on every third thursday that
> some other domain might sign the mail. It means that the domain in question
> signs its own mail with its own signatures. That means that you have to
> know which domain a piece of mail is purporting to be from. The address
> chosen in the requirements in RFC5016 is the rfc2822.From address. This was
> not controversial. Why we're rehash that non-argument now is beyond me.
Because the mechanism is problematic and the choice of From is problematic.
>> Question: Is DKIM for transit validation or is it for content
> This is a false dilemma.
No it is not. In fact it is basic and salient.
Perhaps the difference between the two is not clear to you?
More information about the ietf-dkim