ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] SSP Responsibility Delegation - Security Concerns

2006-08-16 16:46:36
Douglas Otis wrote:

On Aug 16, 2006, at 3:58 PM, Jim Fenton wrote:

Douglas Otis wrote:

There are many cases where a bad actor could spoof an
user(_at_)author(_dot_)com address sent from isp.net.  When isp.net does not
use account specific authentication, or ensure that email-addresses
are permitted only after a verification of the account being able to
receive at that email-address, then these would be other cases where
a problem could exist.

What you're describing are all things that isp.net could do by using
the right protocols, e.g., authenticated submission.  What I'm
describing is a weakness in the protocol that can't be fixed that way.

A 2822.From domain designating a different signing domain should first
understand whether there are steps taken by the signing domain that
offer adequate protection.  One such step might be to ensure that
non-authenticated list messages are not signed with the same signing
domain signature used for authenticated account messages.  Here
designated domains offer a possible solution without the need to
change the email-addresses into different subdomains.

It seems there would be value obtained by taking these steps.  These
steps would allow the ISP's customers an ability to use their services
and have their messages signed while using their email-address.  This
type of use would require the email-addresses being used have been
validated or constrained by the provider prior to their use.
Sure; regardless of the mode of delegation, whether it's done by SSP, or
by delegating a key or by NS delegation, the domain doing the delegating
should first make sure that they're delegating to a responsible party.

This seems like a minor change for the better.  What weakness can't be
fixed by the proper procedures followed by a signing domain?
The one I described:  the inability for a verifier to distinguish an
author signature generated by the delegate from a third-party signature
generated by the delegate operating in a different context.

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