On Jun 7, 2006, at 6:00 PM, Paul Hoffman wrote:
At 5:31 PM -0700 6/7/06, Douglas Otis wrote:
: Keys published by common higher-level domains
:
: Although TLD managers are trustees for the delegated domain, DKIM
: introduces a security concern unrelated to domain delegation.
: Registry Operator Functional Specification Agreements normally
: preclude registering "_domainkey" due to the underscore character.
: This limitation is expected to also preclude TLD managers from
: publishing the "_domainkey" label as a subdomain. There are also
: unsanctioned alternative TLD managers and SLDs managers operating
: under a variety agreements known to include domains exceeding
: normally prescribed characters.
:
: By utilizing the unqualified subdomains of the DKIM-Signature
: header field 'i=' parameter, a DKIM key can be referenced
: from any higher level domain to validate an email-address
: containing these subdomains. This provision might be exploited
: to usurp the validation of an email-addresses of a lower domain.
: As a result, DKIM keys published at a higher level could expose
: subdomains to harm from a possible security breach at a higher
: level and to conflicts with regard to what is a valid
: email-address. For example, the key's 'g=' localpart template
: provision permitting MUA signing does not restrict the
: subdomains that can be included within the DKIM-Signature 'i='
: parameter.
:
: Unless otherwise already preclude by existing agreements, a
: DKIM operator will need to establish separate agreements
: governing the high-level domain's covenants as related to the
: specific use of the "_domainkey" subdomain. These new functional
: requirements should include limitations on key retention periods,
: key sizes, the handling of the private key, and whether
: address validation assertions are permitted within lower
: level domains.
-1, for many of the same reasons stated before. Plus there is now
the new, impossible-to-mitigate threat of alternate roots.
Acquiescing to the status quo as if that offers a solution is not
very helpful from the standpoint of understanding what is in error.
The threat draft is not helpful in this case as it makes some false
assumptions and overlooks important issues. The concern of alternate
roots must be mitigated by separate agreements governing use of these
services, which might occur for political, financial, as well as many
other reasons. The concern is with respect to the use of a
_domainkey subdomain at a higher level. As John suggested, this
should be viewed as a regulatory or contractual issue rather than
technical, but not impossible. The draft would be completely remiss
failing to note these significant security concerns. Keep in mind
the "impossible" problem only exist by offering a DNS publishing
convenience for validating an email-address.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html