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.
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?
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.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html