On Tue, 22 Aug 2006 15:59:00 -0700 Jim Fenton <fenton(_at_)cisco(_dot_)com>
wrote:
Scott Kitterman wrote:
On Monday 21 August 2006 01:34, Jim Fenton wrote:
Scott Kitterman wrote:
Yes, but the fundamental operational problem will be to pick the
correct
domain to sign with. You have to make that decision either way. The
basis upon which you make the decision is the same. I agree that the
result LOOKS less ambiguous with the NS delegation approach, but the
fundamental security issue is don't pick the wrong domain to sign with
and that's no different.
When using the "authorized signing domains" approach, the signer uses
its own domain name, not that of the domain doing the delegation. I
don't see where there is a choice for the signer to make (which is also
the source of the ambiguity).
We had been discussing the need to segregated authenticated traffic
(where
authorization to use the 2822.From has been established) from other
traffic
being signed by use of a subdomain. This is to avoid issues like your
mailing list concern. The authorized signing domain would be the
subdomain
that the operator has designated for the purpose.
Sorry, having trouble keeping the context of the discussion right.
I certainly understand. There are lots of messages flying around all
saying slightly different things.
This could be done, but dilutes the simplicity argument that motivated
the Authorized Signing Domains approach in the first place. Formerly
the ISP just signed using their own domain name; now they must create a
subdomain for each of their customers, publish keys there, and sign each
using the proper subdomain? Or do they sign using
i=(_at_)cust49(_dot_)isp(_dot_)com and
d=isp.com perhaps?
The point that relates to SSP and the feasibility of a desgnated signer
list is that what I've referred to as controlled and uncontrolled traffic
should not be signed with the same domain. This, I think cures your
mailinglist concern.
Whether the operator signs controlled traffic with a single domain or a
different one per customer is not something that I thinks needs to be
standardized now. It is related to reputation and not SSP. I could see an
operator promoting a positive reputation for their signing domain as a
value added advantage. I can equally envision an operator promoting per
customer domain signing so that other customers can't affect the
reputation. None of that matters for SSP. for SSP, all that is needed is
a signing domain that is only used for controlled traffic. If an operator
only deals in controlled trafffic, then no special domain is needed.
But there is a residual problem. Suppose jdoe(_at_)mipassoc(_dot_)org is a
subscriber to this list and someone spoofs a message from
jdoe(_at_)mipassoc(_dot_)org to the list. ietf-dkim(_at_)mipassoc(_dot_)org
accepts the
message and sends it to isp.com, their Authorized Signing Domain, and it
is signed and sent. Is the signature from jdoe (the author) or
ietf-dkim (the mailing list)? Without Authorized Signing Domains, you
could tell by looking at the local-part of i=. But now you can't. I
think this is an important distinction, even if it only applies in a
subset of use cases.
I think if you've painted youself into the looking at localparts of
anything then you've got a scalability problem and not a solution.
I would argue that your example is a case of uncontrolled operations. It
is up to the MSA to prevent forgery. The author in this case is still
jdoe(_at_)mipassoc(_dot_)org(_dot_) If mipassoc.org lists an authorized
signing domain it
needs to be at the very least something like controlled.isp.example.com and
the mailing list traffic (since it's pretty much inherently uncontrolled)
must not be signed by the same domain. It might be just isp.example.com or
some other, more specific, subdomain. It really doesn't matter what.
I've got a very clear picture of how this would work in my mind. I wish I
could devote more time to a concise and more coherent description of this.
Unfortunately, since this is volunteer work for me, I'm having a hard time
carving out dedicated time to work through it. Sorry I'm not doing a
better job of it.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html