Scott Kitterman wrote:
On Friday 18 August 2006 16:32, Jim Fenton wrote:
Scott Kitterman wrote:
What security problems are there with a list of authorized signing
domains that are not equally applicable to the the NS delegation/operator
signs with the author's domain approach? I'm unclear about that. Maybe
we can help each other out.
With key delegation (either with NS, or by publishing a TXT record with
a public key that the signing operator uses), the operator signs using
the author's (or more generally the delegator's) domain name, and can
use i= to specify that the signature corresponds to the author's
address. So it's possible to see that it's an author signature. With
authorized signing domains, the operator signs using its own domain
name, and no association with the specific signing address (either the
local-part, or specification of which delegated domain) is possible.
OK. I got that. Where I'm getting confused I guess is the process for
deciding which domain the operator should sign with....
For reference, I'll differentiate between the two approaches by calling them
the delegator approach (you describe above) and the authorized list approach.
If you know the source that authenticated with the submission -- which I
think
we all agree is needed in the outsourced model -- then you only sign for
that source's
domain. If it happens to correspond to one of the outside headers such
as From:
or Sender: then you set i= to that address and everything works fine.
You never
get into this cross-domain signature ambiguity that Jim brought up.
Mike
In the authorized list approach, the operator receives a message with a
certain 2822.From and the operator signs the message with their
operator.domain. Receivers then can (we postulate) query the SSP associated
with the 2822.From and see what the author has to say about that. This may
result in the receiver treating the operator.domain signature as a first
party signature.
The concern is that if the operator signs messages with that domain's
2822.From that were not actually from an authorized user of that domain (e.g.
it's a forged message) then this treatment is in error and a security risk.
The solution to this concern is for the operator to determine if the message
has been submitted by a source that is verified to be authorized to use that
domain (what I referred to in other posts as controlled operations). Since
essentially no one does that today, this is a large change in operational
paradigm and people are rightfully concerned about it being done incorrectly.
In the delegator approach, the operator receives a message with a certain
2822.From and the operator signs the message with the 2822.From domain.
Receivers then can see a first party signature.
It seems to me that the situation is essentially identical. Operator gets a
message with a certain 2822.From and has to decide what domain to sign with.
In the delegator approach if the operator signs with the 2822.From domain and
the message was forged, there is a security risk that is in my view (at least
as well as I understand it) as bad if not worse than the authorized list
approach.
Once again, the solution is to only sign e-mails with the 2822.From domain if
the source of the mail is known to be authorized to use that domain (the
controlled method of operation).
Either way the operator has to pick the correct domain to sign with and he has
to do it via some kind of information other than just the 2822.From of the
message.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html