[ietf-dkim] Delegating responsibility: a make vs. buy design decision

[Michael Thomas]

Scott Kitterman wrote:

>On Friday 18 August 2006 20:04, Michael Thomas wrote:
>  
>
>>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.
>>
>>    
>>
>Yes, but the fundamental operational problem will be to pick the correct 
>domain to sign with.  
>
If you know the submission authentication information, why is this hard?
They authenticate as foo at bar.com, 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.

>You have to make thatd 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.

       Mike