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

[Michael Thomas]

Douglas Otis wrote:

>On Thu, 2006-06-01 at 15:02 -0700, Michael Thomas wrote:
>  
>
Doug. I didn't write this. It was taken directly from the -threats draft.

       Mike

>  
>
>>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.
>>    
>>
>
>Domain delegation of Registered Names is within global and regional
>Internet Registries current obligations.  However a "_domainkey"
>sub-domain label is not.  How such a label is to be handled remains a
>matter of conjecture without additional regulatory clarification or
>policy changes that might impact existing agreements.  The threat draft
>appears incorrect to dismiss these concerns as representing a
>continuation of current obligations.  This appears to be another error
>that will remain uncorrected in the threat draft. : (
>
>
>  
>
>>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.
>>    
>>
>
>Individual DKIM implementers at lower levels will be unable to assert
>much influence in such a matter.  Should publishing keys at the higher
>level provide a lucrative revenue stream for Registries, the force of
>such influence becomes doubtful.  DKIM implementers may find themselves
>in competition with a coalition of Registries and Certification
>Authorities issuing one-time verified email-certificates.  This may be
>viewed as an unintended consequence, or a "good thing" depending upon
>who benefits.
>
>Such problems, as well as being unable to protect the local name space
>between sub-domains when allowing MUA signing, remains an open issue.
>Either the WG attempts to quickly solve these complex issues, or the WG
>requires keys to be located at the same level as the assured
>email-address.  Simple is safer, and better from an abuse standpoint.
>
>-Doug
>  
>