On 5/3/10 8:58 AM, Alessandro Vesely wrote:
On 02/May/10 13:33, Douglas Otis wrote:
To retain security, the sender's domain needs to assert domain specific
exceptions for "all" or "discard-able" ADSP policies.
That's false, under several acceptations of "security". /Necessity/ of
such assertions only makes sense if "security" is meant to be the
ability of a domain to restrict legitimate uses of its name, such as
its users writing to mailing lists, or to their grandma's.
ADSP "all" or "discardable" with specific third-party authorizations by
a sender's domain does not restrict who may receive their message. This
relates to who is trusted to modify the sender domain's messages.
Lacking a valid signature, specific third-party authorizations permit
enhanced security for recipients while avoiding message loss.
Sender's specific third-party domain authorizations indicate trust in a
third-party service not to make malicious modifications.
When a sender has not found their messages spoofed to mislead their
recipients, they may not see value in making ADSP "all" or
"discard-able" assertions.
When a domain's messages are being spoofed to mislead recipients, there
is no reason to expect spoofing will be limited to transactional
messages. As such, greater security becomes possible without disrupting
services by including a specific third-party authorization mechanism.
Rather than separately signing third-party authorizations within a
message using headers that might be stripped, there would be less
overhead and greater conformance permitted when retrieving a hashed
label from the sender's domain. This would permit use of F2F services
that were specifically authorized. DNS has a DNAME resource record,
that when published at the _adsp node, can synthesize CNAMEs when needed
to permit a vouching service a means to assert authorizations on behalf
many other sender domains. Of course, each sender domain could
selectively authorize third-party services being used as well.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html