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

From: Douglas Otis <[email-masked]>
Date: Thu, 1 Jun 2006 10:19:57 -0700

There should be a security consideration mentioning an unintended  
consequence when a different entity controls sub-domains of a high  
level domain.  This could be viewed as an ICANN, ARIN, APNIC, LACNIC,  
AfricNIC, RIPE NCC, and DENIC consideration advice.  RFC1591 makes  
the following statement:
,---
| There are no requirements on subdomains of top-level domains
| beyond the requirements on higher-level domains themselves.  That
| is, the requirements in this memo are applied recursively.  In
| particular, all subdomains shall be allowed to operate their own
| domain name servers, providing in them whatever information the
| subdomain manager sees fit (as long as it is true and correct).
'___

There did appear to be some consensus this could be viewed as  
requiring contractual rather than technical considerations.  This  
requirement should be indicated within the security consideration  
section at least.

: Security Considerations:
:
: 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.
: Currently there are no contractual obligations barring gTLD, ccTLD,
: or SLD managers from publishing DKIM accessible keys within a
: "_domainkey" sub-domain.  While this sub-domain can not be
: delegated as a domain due to the underscore character '_',
: unqualified sub-domains in the 'i=' parameter can be constructed
: to reference a key published by a higher level domain.  These
: higher level keys expose all sub-domains to harm from a possible
: security breach at these higher levels.  The only protection
: available to owners of all sub-domains would be established
: contractual obligations that currently do not exist.  The simplest
: remedy would be to ban inclusion of any sub-domain beginning with
: the underscore '_' within these common higher-level domains.

-Doug

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 01 Jun 2006 19:10:00 +0100

Thanks Doug,

Douglas Otis wrote:
> consequence when a different entity controls sub-domains of a high level 
> domain.  This could be viewed as an ICANN, ARIN, APNIC, LACNIC, 
> AfricNIC, RIPE NCC, and DENIC consideration advice.  RFC1591 makes the 
> following statement:
> ,---
> There did appear to be some consensus this could be viewed as requiring 
> contractual rather than technical considerations.  This requirement 
> should be indicated within the security consideration section at least.
> 

Eliot, can you raise this as a new issue as discussed at the
jabbering today?

Ta,
S.

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 1 Jun 2006 11:33:26 -0700 (PDT)

On Thu, 1 Jun 2006, Douglas Otis wrote:

> There should be a security consideration mentioning an unintended consequence 
> when a different entity controls sub-domains of a high level domain.  This 
> could be viewed as an ICANN, ARIN, APNIC, LACNIC, AfricNIC, RIPE NCC,

Could you explain what the ip registries (ARIN, APNIC, LACNIC, AfriNIC,
RIPE) have to do with domain-based authentication protocol?

Note: they do indirectly if somebody hijacks ip address of dns server, but
the what Doug is talking about does not seem to be it.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Thu, 1 Jun 2006 11:43:54 -0700

On Jun 1, 2006, at 11:33 AM, william(at)elan.net wrote:

>> level domain.  This could be viewed as an ICANN, ARIN, APNIC,  
>> LACNIC, AfricNIC, RIPE NCC,
>

The current obligations are strictly related to domain delegations,  
as you suggest.  However DKIM introduces new business opportunities  
for these organizations.  Only regulatory bodies would be in a  
position to establish any requisite limitations regarding the use of  
sub-domains as related to DKIM within their domain.

Parent signing introduces currently non-existent contractual  
obligations and liabilities related to the publishing of DKIM keys.   
Simple prohibition of any such publishing by global and regional  
Internet Registries would be the simplest solution.  Whether these  
organizations view publishing DKIM keys within their prerogative may  
depend upon whether there is a business model that exploits their  
control of domains considered authoritative for all email-addresses  
below this domain.

Speculating on the possible business model, outbound SMTP services  
could be offered to those able to authenticates with a certificate  
from a recognized CA that identifies their email-address, for  
example.  These messages could then be signed by the TLD domain where  
the i= parameter would indicate the identity found within the  
certificate.  These TLD signed messages could then be considered an  
elite assurance that the message will not be abusive.  The location  
of these keys however introduces the possibility of catastrophic  
failure which should involve regulatory oversight.

-Doug

---

From: Eliot Lear <[email-masked]>
Date: Thu, 01 Jun 2006 20:47:10 +0200

Stephen Farrell wrote:
>> level domain....
Done. Issue # 1285.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 1 Jun 2006 12:28:50 -0700

>: the underscore '_' within these common higher-level domains.

This has many technical flaws that would need to be addressed before 
we put anything like it in the base spec. Taken sentence by sentence:

- This is not about TLDs. As many people have pointed out earlier, it 
affects all levels of delegation. This includes the root. As long as 
we are considering implausible security threats, we should remember 
that ICANN might put _domainkey in the root, put a key there, then 
have it compromised in a way that threatens all DKIM users.

- Even if the second sentence is true (and I doubt anyone here has 
done the research to say whether or not it is), it is misleading. It 
is just fine if a higher-level zone publishes a key: it is only bad 
if that key is compromised.

- The third sentence is misleading unless you change "can be 
constructed" to "can be constructed by an attacker who has 
compromised the higher-level's key and then sends out mail signed 
with the compromised key during the period before the higher-leve's 
key is still being distributed".

- The fourth sentence needs to define the "harm". That will help 
readers understand just how little threat there is. It might also 
cause the WG to decide that this threat is so insignificant that it 
doesn't need to be listed in the document.

- The fifth sentence is false. There is lots of other protection 
available, namely the fact that the compromised key can be replaced 
as soon as the attacker starts using it.

- The sixth sentence is false in that it is not the simplest remedy. 
ICANN has fewer than 10% of all of the TLDs in the root under 
contract, which makes this change anything but simple. A simpler 
remedy would be for people in lower-level zone who discover an 
unexpected key in a higher-level to complain and possibly shame the 
owner of the higher-level key to stop publishing it.

If the WG thinks that this is a credible threat, the proposed 
paragraph should be changed to deal with these issues before we 
consider it for inclusion in the base draft.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 1 Jun 2006 12:54:10 -0700

On Jun 1, 2006, at 12:28 PM, Paul Hoffman wrote:

> This has many technical flaws that would need to be addressed  
> before we put anything like it in the base spec. Taken sentence by  
> sentence:
>
> - This is not about TLDs. As many people have pointed out earlier,  
> it affects all levels of delegation. This includes the root. As  
> long as we are considering implausible security threats, we should  
> remember that ICANN might put _domainkey in the root, put a key  
> there, then have it compromised in a way that threatens all DKIM  
> users.

There are prohibitions against delegating a domain with the  
underscore.  That prohibition may preclude seeing a _domainkey label  
at the root.  I also doubt that a DKIM verifier would accept d=; as a  
valid domain.

> done the research to say whether or not it is), it is misleading.  
> It is just fine if a higher-level zone publishes a key: it is only  
> bad if that key is compromised.

There are broader implications regarding who is authoritative as  
well.  From a quick review, the general limitations relevant to DKIM  
appear to be within RFC1591.

> key is still being distributed".

Where the system of the TLD is compromised does not seem all that  
relevant.  Perhaps this could be modified to say "constructed by a  
bad actor" ?

> doesn't need to be listed in the document.

The harm of a compromised key is already defined in the threat draft  
as having a high impact.  I am not happy with the threat draft  
definition of impact.  Even so, perhaps harm could be replaced with  
"a high impact" ?

> as soon as the attacker starts using it.

This assumes the nature of the exploit and who will replace the key.   
The effected party may have no business relationship with TLD  
provider other than a domain delegation.  How will the affected party  
learn of the exploit in a timely manner?  There would be no server  
activity that could be used as an alert.

> - The sixth sentence is false in that it is not the simplest  
> remedy. ICANN has fewer than 10% of all of the TLDs in the root  
> under contract, which makes this change anything but simple. A  
> simpler remedy would be for people in lower-level zone who discover  
> an unexpected key in a higher-level to complain and possibly shame  
> the owner of the higher-level key to stop publishing it.

If the TLD finds this to be a new revenue source, shame may not be  
enough however.

> consider it for inclusion in the base draft.

Of course, the WG must decide on the language, but this should still  
be included within the security consideration section.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Thu, 01 Jun 2006 15:02:04 -0700

Douglas Otis wrote:
[]

My suggestion this morning was that if we include this in the security 
considerations
at all, that we just lift it from the -threats draft since that has 
already been vetted.
Here's what's there now:

4.1.18.  Key Publication by Higher Level Domain

   In order to support the ability of a domain to sign for subdomains
   under its administrative control, DKIM permits the domain of a
   signature (d= tag) to be any higher-level domain than the signature's
   address (i= or equivalent).  However, since there is no mechanism for
   determining common administrative control of a subdomain, it is
   possible for a parent to publish keys which are valid for any domain
   below them in the DNS hierarchy.  In other words, mail from the
   domain example.anytown.ny.us could be signed using keys published by
   anytown.ny.us, ny.us, or us, in addition to the domain itself.
   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.

FWIW, I'm neutral as to whether we need to include this threat in -base 
or not.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 01 Jun 2006 17:24:57 -0700

On Thu, 2006-06-01 at 15:02 -0700, Michael Thomas wrote:

> 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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 01 Jun 2006 17:39:47 -0700

>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

---

From: Douglas Otis <[email-masked]>
Date: Thu, 01 Jun 2006 17:47:36 -0700

> Doug. I didn't write this. It was taken directly from the -threats draft.

My apologies.  I trimmed your email to just the critical sections.  I
should have included your note that this was from the Threat draft.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 1 Jun 2006 17:52:01 -0700

At 5:24 PM -0700 6/1/06, Douglas Otis wrote:
>. . .without additional regulatory clarification or
>policy changes that might impact existing agreements.

The DKIM WG making DNS policy for ICANN should be considered out of 
scope for the WG.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 01 Jun 2006 18:17:21 -0700

> The DKIM WG making DNS policy for ICANN should be considered out of 

I agree with you about deleting the suggested remedy.  Such a provision
that bans the use of DKIM keys or perhaps the underscore label could be
more complex than imagined.

The rationale for this being included within the Security Consideration
section was to highlight an expectation that a regulatory body may need
to act.  This could be seen as analogous to an IANA consideration
section.  As was mentioned, this could be viewed as a notice to ICANN,
ARIN, APNIC, LACNIC, AfricNIC, RIPE NCC, and DENIC.

A DKIM implementer might also need to include DKIM related security
terms and conditions with private providers in conjunction with future
or existing services as related to the publishing of DKIM keys and their
use.  This is a new security related element independent of normal
domain delegation obligations.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Thu, 01 Jun 2006 18:37:26 -0700

>domain delegation obligations.
I have no idea what this means, so I'm virtually certain I'm not going 
to do it.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Fri, 2 Jun 2006 09:37:11 -0700

On Jun 1, 2006, at 6:37 PM, Michael Thomas wrote:

> I have no idea what this means, so I'm virtually certain I'm not  
> going to do it.

Additional obligations are needed specifically due to the fact that  
DKIM currently permits any high level domain to claim authority over  
the i= parameter.  This consideration vanishes by mandating the  
domain assured in the i= parameter must be the same domain as that of  
the key.  This parity would ensure existing domain delegation  
obligations protect the use of the i= parameter.   This parity also  
resolves the g= problem as well.  Without key parity, retirement  
rates, key size, private key half handling and i= assertions all  
become new concerns to be negotiated by both regulatory bodies and  
DKIM implementers when obtaining delegations from private providers.

Think of the receivers...

Increased efforts by the receiver greatly outweigh reduced efforts of  
the transmitter.  This practical reality works against CNAMES with  
selectors, for example.  Allowing any number of sub-domains  
represented by a single parent domain may force receivers to list  
unacceptable sub-domains when the parent signing domain represents  
too many legitimate email sources to block.  Should the domain allow  
MUA signing, the number of sub-domains that might be used becomes  
unlimited.  At that point, blocking at the key becomes necessary  
which also greatly increases the burden on the receiver where  
blocking John.Doe@bar would also block [email-masked], for  
example.  Instead of allowing the receiver to base acceptance on the  
domain, the receiver is forced to resolve acceptance based upon a  
much greater number of keys.  This is unrealistic and onerous.  Far  
more onerous than what would be expected of the transmitter when  
requiring validation parity with that of the signing domain.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 7 Jun 2006 17:31:34 -0700

: Security Considerations:
:
: 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.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Jun 2006 18:00:47 -0700

>: address validation assertions are permitted within lower

-1, for many of the same reasons stated before. Plus there is now the 
new, impossible-to-mitigate threat of alternate roots.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Wed, 07 Jun 2006 18:23:13 -0700

> new, impossible-to-mitigate threat of alternate roots.

As far as I can tell, there's been no ground swell for either Doug's 
tome or my suggestion
of just copying in section from the threats document. I personally take 
that as people
being happy with the current state of the draft which is fine by me too.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 7 Jun 2006 18:40:32 -0700

On Jun 7, 2006, at 6:00 PM, Paul Hoffman wrote:

> -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