[ietf-dkim] requirements

[Michael Thomas]

Scott Kitterman wrote:

>On Wednesday 26 July 2006 16:36, Michael Thomas wrote:
>  
>
>>Scott Kitterman wrote:
>>    
>>
>>>On Wednesday 26 July 2006 14:14, Michael Thomas wrote:
>>>      
>>>
>>>>This is a really good instance of what the base level requirements are.
>>>>On the one hand we can say that the requirement is that an ISP signing
>>>>on behalf of a customer actually sign on behalf of the customer. That
>>>>is, the d=customer.com rather than d=isp.com.
>>>>
>>>>What I see here is the desire to actually have d=isp.com with the policy
>>>>saying that that is ok. One downside of this is that you'd require a
>>>>policy lookup because the From: address would still be customer.com, not
>>>>isp.com (ie, it looks like a third party). On the other hand, it doesn't
>>>>seem like it's a very big burden on the signing software to know what
>>>>domains it signs for, but I'm not as convinced about that from an
>>>>operational standpoint.
>>>>        
>>>>
>>>Agreed.
>>>
>>>I see it as a complexity tradeoff between managing multiple keys for
>>>multiple domains versus a single key for the ISP's domain and doing
>>>additional policy lookups for ISPs that sign 3rd party for their hosted
>>>domains.
>>>      
>>>
>>I think the issue of multiple keys is orthogonal as you could use one
>>key in either scenario. My code, for example, currently supports either
>>key scenario: one key for multiple domains, different keys for different
>>domains, etc. I think the issue is whether the signer needs to keep track
>>of all the domains it signs for or not. It seems to me that it would
>>though, and if that's the case I'm not sure if it's worthwhile having
>>indirection at the policy layer instead of just doing at the signing layer.
>>
>>    
>>
>
>  
>
>I don't know how detailed the requirements document you are working on is 
>intended to be....
>  
>

I think it needs to be detailed enough that we capture the high level
uses and their implications, but no more.

>This has several lower level requirements that I can think of offhand for the 
>signer:
>
> - Ensuring that messages that are signed for a domain are from an authorized 
>source for that domain.
>
> - Signing the message in a way that allows receivers to know that the 
>signature is an authorized signature for the sending domain (and this could 
>be first party using one or more keys or 3rd party with a policy record that 
>indicates that the signer is authorized)
>
> - Public or Public/Private (depending on how the previous requirement is 
>satisfied) key exchange and maintenance.
>  
>

I think these are largely captured in dkim-base or the -threats 
documents but:

>The domain owner will have to publish the key and possibly  a policy record in 
>their DNS.
>  
>
In thinking more about both your and Bill's comments it occurs to me 
there is
another advantage of the policy indirection that was being discussed: if an
ISP signs for a bunch of domains and decided that it needed to change a
signing key, that key would need to be updated in all of the DNS zones
it signs for which may be quite painful.

This could possibly be dealt with in a couple of ways:

1) make all of the customer's zones change (bletch).
2) customer delegates the _domainkey subdomain to the provider so they
    can manage it on the customer's behalf (probably only scales to one 
provider
    though)
3) have the ability for the policy statement say that a provider(s) 
legitimately
    signs for that domain.

(2) puts the responsibility for management of the zone on the email 
service provider
which may not be very natural. (3) has scaling issues transport if there 
were to be
more than one entity allowed to sign for a domain, which seems like a 
likely use
case too.

There may be ways to tease these use cases apart though. I'm sort of 
inclined to
put (3) in the requirements to capture the issue even if we ultimately 
decide that
it's not a good idea and abandon it.

       Mike