On Tue, 22 Aug 2006 15:59:00 -0700 Jim Fenton <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] is a
>subscriber to this list and someone spoofs a message from
>[EMAIL PROTECTED] to the list. [email protected] 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
[EMAIL PROTECTED] 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
