On Sat, 2006-08-19 at 15:49 -0700, Michael Thomas wrote: > Scott Kitterman wrote: > > On Friday 18 August 2006 20:04, Michael Thomas wrote: > >> Scott Kitterman wrote: > >> > >>> 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. > > > > Yes, but the fundamental operational problem will be to pick the > > correct domain to sign with.
There are two possible secure modes. One is where the service provider has obtained either the private key/location, or has control of a delegated zone to sign with matching signing and 2822.From domains. Signing with an external domain must be restricted to domain validated accounts. Perhaps each account must offer key/location information to validate the use of that domain. Offering zone delegation information is easily spoofed. This still leaves the 2822.From validation when signing for a different domain. What is required to safely use the i= syntax that indicates the 2822.From is valid? Reliance upon per user keys will be difficult to scale and will generally risks DNS when done on a large scale. The policy based mode saves several steps, and unnecessary use of different keys. This mode simply places a general restriction at the outbound MTA on the 2822.From address per account. The message is signed with the service provider's normal key under their domain. This 2822.From restriction mechanism is required even when a matching signing domain is available. This mechanism must exist to ensure the valid use of the 2822.From address. In either mode of operation, a 2822.From validation/restriction step is required to ensure the 2822.From address is valid at the outbound MTA. Matching the signing domain with the 2822.From domain is an unnecessary extra step. Exchanging key/location information adds no additional security when this 2822.From restriction is applied by the provider. > If you know the submission authentication information, why is this > hard? They authenticate as [EMAIL PROTECTED], that means I pick the key for > bar.com (and potentially foo if there's a g=). This doesn't seem like > rocket science to me. Verification of foo and bar should be viewed as separate issues. If an account is being arranged that acts as a relay of corporate servers, then a key/location approach should be used. The provider would still need to ask whether the 2822.From addresses are assured to be valid. To allow their outside employees access to the provider's general account facilities, this provider could also be added as a designated provider when 2822.From validation restrictions are in place at the provider. When this restriction is in place, then the 2822.From policy could assert the addresses are "Valid". > > 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. > > No, the fundamental problem is that there's no way for a signer to > relay that information to the receiver via i= when you're a third > party. A "2822.From is valid" assertion can also be conveyed by the 2822.From policy as well as the i= syntax. When there is a list of designated domains in the 2822.From policy, and the 2822.From is asserted as not being valid, then only signatures with matching domains could override the "Invalid" assertion made in the policy. On the other hand, if only DKIM signing domains that restricted the outbound 2822.From address (pending receipt-verification) were listed, then it would be safe for their 2822.From policy to assert that all 2822.From addresses are valid. Signatures with a matching domain could override the Valid/Invalid assertion made by the 2822.From policy. The 2822.From Valid/Invalid assertion would only apply when the 2822.From and signing domains do not match. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
