Dave Crocker wrote:
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".
Defeated. Utterly. Trivially. It would be the equivalent to the
IETF trying to standardize an 8 bit encryption scheme.
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.
mtcc.com SSP: p=strict;
From: mike(_at_)mtcc(_dot_)com
DKIM-Signature: i=foo(_at_)hacker(_dot_)com;
Subject: phish is yummy
If you're going to say that this signature qualifies as acceptable for
the above SSP record, then you have created a security hole that renders
SSP utterly useless.
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.)
Useless to whom? The SSP protocol? Yes, it's completely useless as
that signature doesn't emanate from that domain. If you're talking
about a receiver in general, that is completely out of scope of SSP;
the receiver is entitled to attach as much (ir)relevance to that
signature as it sees fit.
Period. That
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.
Problematic? It's central, and well documented in RFC5016.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html