Re: [ietf-dkim] Not exactly not a threat analysis

Earl Hood wrote:

> On August 23, 2005 at 13:53, Jim Fenton wrote:
>
>  
>
> > This goes to what we have been very generically calling first-party and 
> > third-party signatures.  The original submission of a message would 
> > normally result in a first-party signature from the supposed author's 
> > domain.  A mailing list would apply a third-party signature, which can 
> > be distinguished by the fact that i= does not match the originator's 
> > address.
> >    
> I think this is a weak inference.
>
> I'm not sure it is safe to infer that a "first-party" signature can
> be adequately represented by the i= matching the OA.  First, i= does
> not have to be complete mailbox specification, so all you have to go
> by is the domain portion.
>  
My personal preference has been and is to have a full i= specification 
whenever possible; if it were up to me, I would probably turn around the 
wording and say that the local-part is required unless the signing 
domain is unable or unwilling to commit to a specific address.  If the 
local part of i= is missing, you just need to assume that it matches any 
address in the domain; there is a small exposure if a third-party 
signature is applied by the same domain.
> Then, what about service relationships where the author/sending
> party is of one domain, but submit all mail through another domain
> (due to a service agreement between the two parties)?
>
> In order to satisfy the first-party aspects of the signature,
> the mail service domain would have to make sure that the i= and d=
> match the OA's domain, and that the OA domain defines the correct
> DNS records (which the mail service domain may not have the ability
> to do directly) to support signature validation.  This makes key
> management a problem since the mail domain will own the private key,
> but not have the direct ability to publish the public key.
>  
Assuming we're talking about DNS key publication, the OA domain could 
just delegate its _domainkey subdomain to the mail domain, which would 
give it the ability to directly publish the public key.  Otherwise, the 
mail domain would need to tell the OA domain the keys to publish.
If there are multiple mail domains, this can be accommodated through the 
use of dotted selectors:  the OA domain delegates subdomains of their 
_domainkey space (e.g., mailservice1._domainkey.example.com) and the 
mailing service uses keys with selector names like alpha.mailservice1 to 
sign.  The OA domain needs to bear in mind that any such delegation 
gives authority to sign for any address in the domain, so it must be 
done judiciously.
> Wrt key management, if the OA domain has the ability specify who is
> allowed to perform "first-party" signatures (like through the SSP
> record), the mail service domain can handle all the key management
> issues without having to coordinate with the OA domain.  This can be
> a problem if keys are rotated on a frequent basis.  SSP records will
> be more stable, so OA coordination is not as involved.
>  
It would be nice to be able to avoid the second SSP lookup, and I'm also 
concerned with the scalability of this to many mailing domains.  I 
recall a statistic that Bank of America employs something like 128 
different outside services to send mail on its behalf; I don't think you 
want the SSP record enumerating those (it won't fit in a UDP DNS lookup, 
for starters).
>  
>
> > BTW, a good reason for the local-part on i= is that it if the original 
> > purported author and the mailing list are in the same domain, it's still 
> > possible for the list to apply a signature and not have it look like a 
> > first-party signature.
> >    
> Are you saying for a signature to be "first-party" the i= must
> of a complete mailbox address value?
>  
Either that or the local-part of the mailbox address isn't checked 
(i.e., matches anything) if the local-part of i= is blank.  I don't 
think the spec is explicit on that point.  But in that case, there is an 
undesirable possibility that a third party signature could be 
interpreted as first-party if someone spoofs a From address in the 
third-party's domain.
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org