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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html