[ietf-dkim] base-02 // Parent signing security considerations/ summation

[Douglas Otis]

Further clarifications regarding the concern dismissed in the jabber  
session. : (

base-02 // Parent signing security considerations v.2

http://mipassoc.org/pipermail/ietf-dkim/2006q2/003830.html

The view against change suggests this issue is synonymous with DNS  
delegation and is also largely the point made in the threat draft.

Threat-03:
,---
| 4.1.18.  Key Publication by Higher Level Domain
|...
| Operation of a domain always requires a trust relationship with
| higher level domains.  Higher level domains already have ultimate
| power over their subdomains:  they could change the name server
| delegation for the domain or disenfranchise it entirely.  So it is
| unlikely that a higher level domain would intentionally compromise a
| subdomain in this manner.  However, if higher level domains send mail
| on their own behalf, they may wish to publish keys at their own
| level.  Higher level domains must employ special care in the
| delegation of keys they publish to ensure that any of their
| subdomains are not compromised by misuse of such keys.
'___

The view supporting change suggests there is a significant risk to  
the security of email-address validations caused by the 'i='  
subdomain provision that only makes it convenient to sign messages  
using a common key within a higher level domain.  For example, a  
feature within the key is intended to restrict the local-part of the  
email-address when allowing a notebook to sign messages by the MUA.   
While the key may restrict the use of the local-part, the key can not  
restrict the use of subdomains in the 'i=' parameter.  There is no  
means to confine email-address validations between subdomains by  
_any_ compromised or misused key due to the lack of the 'i='  
parameter subdomain prohibition. (i.e. i=<localpart> allowed,  
i=@<subdomain> prohibited)  Prohibiting the use of'i=' subdomains  
forces keys to be referenced from the email-address domain.  This  
prohibition leverages DNS delegation and ensures an email-address  
validation is controlled by the delegated domain owner, while also  
providing greater source granularity.

Either DKIM prohibits subdomains being used within the i= parameter,  
or domain delegation related service agreements may need to specify  
use of the "_domainkey" subdomain within higher level domains.   
Currently this consideration is not mentioned as it is assumed an  
existing trust relationship somehow assures these details.  DNS  
delegation and the many related DNS security concerns are wholly  
unrelated to concerns regarding the use of non-delegated '_domainkey'  
subdomains within higher level domains.  The DKIM security  
considerations for non-delegated subdomain use represents a new  
requirement not likely covered by existing agreements.

A Security Consideration section should be specific about these  
additional concerns.  Concerns include the names allowed within  
higher level domains, and about the conditions imposed upon a higher  
level domain publishing a '_domainkey' subdomain.  In other words,  
the security consideration section should clarify what is meant by  
"special care" that now needs to be included in DKIM implementer's  
SLAs and the covenants established or maintained by regulatory bodies  
of domain services.  When a higher level domain is permitted to  
include a '_domainkey' subdomain, additional requirements should  
include limitations on key retention periods, key sizes, the handling  
of all private keys, and whether address validation assertions are  
permitted within lower level domains.

-Doug