Subject: [ietf-dkim] Issue #1265: Signing by parent domains

From: Jim Fenton <[email-masked]>
Date: Thu, 25 May 2006 20:32:46 -0700

This message is to summarize the issues and kick off a thread on issue
1265, "Signing by parent domains".  The ticket can be viewed at
https://rt.psg.com/Ticket/Display.html?id=1265  (use username/password
ietf/ietf).  Previous discussion on this topic is in the thread that
begins with http://mipassoc.org/pipermail/ietf-dkim/2006q2/003231.html

The issue boils down to whether the domain from which the public key is
obtained, specified by d= in the signature, must be exactly the same as
the domain part of the signing address (i=) or if it can be a parent
domain.  In other words, if d=example.com and i=[email-masked], is
the signature valid or misformed?

So here are some of the issues:

Advantages of parent signing:

- Reduces need to publish duplicate copies of all key records for every
subdomain in existence. 

- Suppose example.com has 20 signing MTAs (about Cisco's number), each
of which signs with its own key, and 5 subdomains which share the 20
MTAs.  This means that 100 extra key records are needed to sign for the
subdomains, and when keys roll over another 100 new records are needed,
and then the original 100 are withdrawn.  This is getting to be a lot of
duplicate records.

Disadvantages of parent signing

- Existence is the attack described in section 4.1.18 of -threats.  For
example, publication of keys for .com which would be able to sign for
any .com domains would be worrisome, especially if such keys (which
would now be very valuable) were to be compromised.  Many such domains
would not be pleased to learn that there is another entity that could
sign their messages.  Restricting TLDs from publishing keys would not
help for situations like .co.uk or even .k12.ca.us.

- Increases exposure to DNS attacks at higher levels that might not be
otherwise detected by the subdomain.

Rebuttal:

- The parent domain ultimately controls the subdomain's fate through
ownership of its NS records, so a trust relationship has to exist
anyway.  Any parent trustworthy to own a subdomain's DNS records is
trustworthy enough not to publish keys and sign maliciously, or to
mismanage any keys they do publish

More discussion:

- Peter Koch (who raised this issue initially) said on the chat that
"the problem...is less that the 'parent domain' ... would 'attack' their
children, but more that it would lead to defaulting up the tree."

I'm not sure what constitutes "defaulting up the tree" in this context. 
Upward searches are never made for key records, because their actual
location is specified in the signature.  If the key isn't at that exact
location, the signature is invalid.

- Concern that 'parent signing' could limit what the maintainer of the
parent zone could enter into their zone, since it could affect a part of
the namespace that was actually delegated out and in the hands of the
child zone maintainer.

I don't think such a namespace conflict is possible with DKIM.  The
_domainkey separator between the selector name and the domain prevents a
key record published by a parent domain from conflicting with another
with the same selector name in a subdomain. 
"nebraska._domainkey.example.com" can be different from
"nebraska._domainkey.sub.example.com"; which one you select depends on
whether d=example.com or d=sub.example.com

A suggestion:

Eric Allman suggests that one way of avoiding the problem is to use
CNAME records; for example:
    _domainkey.sub.example.com  IN  CNAME  _domainkey.example.com

I haven't tried this both with and without zone cuts between example.com
and sub.example.com, but if they're in a common zone at least, I can't
lookup a key record via a selector using the CNAMEd domain.

More discussion, please!

-Jim

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

---

From: John Levine <[email-masked]>
Date: 26 May 2006 05:23:20 -0000

The arguments against parent signatures seem to me to boil down to
two: parents may be untrustworthy, and foolish people can do foolish
things.

I concur with Jim's rebuttal to the first.  The DNS works on the basis
of delegation from the top down, subdomains are 100% at the mercy of
their parent domains whether you like it or not, and it's 25 years too
late to change it.  Sorry.

The problem with the second objection is that the range of foolish
things is vast and unlimited, and this strikes me as what Bruce
Schnier calls a movie plot threat, exciting to imagine, but less
likely in practice than many other kinds of foolishness.  It's a bad
idea to try to enumerate and forbid every foolish thing that people
can do, because fools are very creative, your list will be incomplete,
and if your list is long and detailed, the fools will then insist that
since their foolishness isn't on the list, it must be OK.

An important argument in favor of parent signatures involves wildcard
MXes.  In some of my domains I have an MX for, say, *.example.com.
This lets every user in that domain use his or her domain name as a
subdomain, so that if you send mail to [email-masked],com, the MTA
rewrites the mailbox to an address extension and handles that as mail
to [email-masked].  Qmail lets you do this with about three
lines of config file, so I assume it's easy with other MTAs as well.
Wildcard MXes have a range of uses like this, encoding part of what
might otherwise be the mailbox or other routing or delivery info into
the domain.

DKIM can't handle this if you don't permit parent signing, because the
DNS doesn't permit internal wildcards.  If the signing domain has to
match the mail address domain, the wildcard selector would have to be

selector._domainkey.*.example.com

but that doesn't work.  Using plain *.example.com makes all the
selectors equivalent, which is bad.  You'd have to export your entire
list of users into the DNS, with records like

selector._domainkey.jeff.example.com
selector._domainkey.joe.example.com

and so forth.  For a large mail system, that's a huge DNS bloat and a
and needless burden.

So as far as I am concerned, parent signing is an important and useful
facility with no disadvantages.

R's,
John

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 26 May 2006 12:03:49 -0500

I think it's important to maintain the ability for parent signing in 
order to keep the number of keys required in DNS to a minimum.  Anyway, 
subs are already at the mercy of the parent so isn't this sort of a mute 
point?

-- 
Arvel

---

From: Mark Delany <[email-masked]>
Date: Fri, 26 May 2006 17:49:37 +0000

> subs are already at the mercy of the parent so isn't this sort of a mute 

Heh. We can wish :>

Sadly, on some lists, moot is not a precursor to mute.

Mark.

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 26 May 2006 13:32:59 -0500

> Sadly, on some lists, moot is not a precursor to mute.

Ha ha... that's very true.

-- 
Arvel

---

From: Douglas Otis <[email-masked]>
Date: Fri, 26 May 2006 11:55:06 -0700

On May 25, 2006, at 10:23 PM, John Levine wrote:

> two: parents may be untrustworthy, and foolish people can do  
> foolish things.
>
> I concur with Jim's rebuttal to the first.  The DNS works on the  
> basis of delegation from the top down, subdomains are 100% at the  
> mercy of their parent domains whether you like it or not, and it's  
> 25 years too late to change it.  Sorry.

Any weakness or exploit related to selections of algorithms or keys  
within the DNS hierarchy related to DKIM parent signing precludes an  
effective response at affected levels.  If a TLD used DKIM with 768  
bit keys for example, that might be adequate when this domain's  
messages are seldom targeted.  On the other hand, <big- 
financial>.<tld> may need to react to a highly targeted attack  
employing greater resources, perhaps necessitating 1024 bit keys or  
greater.

Critical and targeted domains will be in an awkward position  
insisting unusual (movie plot) exploits are something that all their  
TLDs must defend against.  When allowing parent signing, <big- 
financial>.<tld> will be unable to directly respond to all threats  
affecting them.  By allowing parent signing, messages for <big- 
financial>.<tld> might be validated by a compromised key at <tld>.   
Perhaps <tld> retains keys for too long, or uses a key too small to  
resist the level of attack amassed against <big-financial>.<tld>.  Of  
course, the greater number of messages compromised by a single key,  
the greater the threat.

This concern is not directly related to how DNS works, but rather  
what message email-addresses are considered confirmed by a  
signature.  There is a significant reduction in security in this  
regard when parent signing is permitted.  When disallowing parent  
signing as directly validating some sub-domain email-address, the  
parent domain can still sign these messages, but would be properly  
considered a third-party signing-domain.  For most messages, this  
should not cause any problem.

-Doug

---

From: "John R Levine" <[email-masked]>
Date: 26 May 2006 17:00:49 -0400

> employing greater resources, perhaps necessitating 1024 bit keys or

This is a contract issue, not a technical issue.

> There is a significant reduction in security in this
> regard when parent signing is permitted.

That's simply untrue.  A malicious or incompetent parent can make
arbitrary changes to any of its delegated domains.  If you consider a
parent domain to be untrustworthy, its subdomains have no security
whatsoever regardless of any rules we might try to invent.

So as I said, parent signatures are quite useful and have no
disadvantages.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 26 May 2006 16:19:10 -0700

On May 26, 2006, at 2:00 PM, John R Levine wrote:

>> If a TLD used DKIM with 768 bit keys for example, that might be  
>> adequate when this domain's messages are seldom targeted.  On the  
>> other hand, <big-financial>.<tld> may need to react to a highly  
>> targeted attack employing greater resources, perhaps necessitating  
>> 1024 bit keys or greater.
>

Few entities are in a position to negotiate security details relevant  
to DKIM keys within higher-level domains.  Will ICANN include such  
details within their security and operations criteria contracts?  For  
the convenience afforded blindly asserting parent signing is  
authoritative for sub-domain email-addresses, are you suggesting  
gTLD, ccTLD, and SLD domain service contracts should specify-

1) Permitted hashing, type and size of keys published for DKIM?

2) Retention period of keys published for DKIM?

3) Security of systems and MTAs that handle the private portion of  
the DKIM key pair?

Should there be a paragraph in the base draft that lists these xLD  
requirements separately?

>> There is a significant reduction in security in this regard when  
>> parent signing is permitted.
>
> That's simply untrue.

A domain name provider may be extremely proficient at securing domain  
delegations and fulfilling SLAs.  By permitting DKIM parent signing  
to validate email-addresses within sub-domains, security lapses  
wholly unrelated to DNS now impact entities well beyond their control  
and perhaps even their knowledge.  With DKIM parent signing being  
considered authoritative, rather than as a third-party, one  
compromised DKIM key can negatively impact security for an entire top  
level domain.

A verifier should not expect any parent domain to be authoritative  
for what is a valid sub-domain email-address.  Annotations related to  
the email-address should not rely upon baseless assertions by the  
DKIM draft of an unconfirmed relationship.  Confirming this  
relationship may involve replicated information, but this information  
also limits the scope of security risks.  This extra information is  
only required when third-party signatures are not sufficient.

> A malicious or incompetent parent can make arbitrary changes to any  
> of its delegated domains.
>
> If you consider a parent domain to be untrustworthy, its subdomains  
> have no security whatsoever regardless of any rules we might try to  
> invent.
>

A significant risk is created by the convenience sought making a  
baseless assertion that parent signing is always authoritative for  
sub-domain email-addresses.  While a parent domain may be  
authoritative in some cases, in many more cases this is not a valid  
assertion.  There is no dire impact disallowing this baseless  
assertion.  Either add the replicate information, or these messages  
can still be signed by the parent domain, but viewed as being signed  
by a third-party.

DKIM key management is not DNS management.  This is like comparing a  
doctor to that of a lawyer.  You may trust them both, but for  
different services.  Insecure DKIM keys within a TLD or SLD domain  
will cause a significant negative impact and will also make them a  
prime target when employing DKIM.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 26 May 2006 17:06:19 -0700

The semantics of i= are *completely clear*:
    d=   The domain of the signing entity (plain-text; REQUIRED).  This
        is the domain that will be queried for the public key.  This
        domain MUST be the same as or a parent domain of the "i=" tag
        (the signing identity, as described below).  When presented with
        a signature that does not meet this requirement, verifiers MUST
        consider the signature invalid.
It doesn't matter how good or bad the maintainer of the higher-level 
domain is: all that matters is what the signer puts in d=. If 
i=[email-masked] and d=mail-abuse.org, then it makes not a whit 
of difference what the key policies and so on of .org are because the 
verifier will never look there.

Stated another way, what part of "This is the domain that will be 
queried for the public key" has anything to do with the DNS hierarchy?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 26 May 2006 18:08:46 -0700

On May 26, 2006, at 5:06 PM, Paul Hoffman wrote:

> It doesn't matter how good or bad the maintainer of the higher- 
> level domain is: all that matters is what the signer puts in d=. If  
> i=[email-masked] and d=mail-abuse.org, then it makes not a  
> whit of difference what the key policies and so on of .org are  
> because the verifier will never look there.
>

Here is a different example:

A message is signed with the following:

... i=[email-masked] d=some-domain.co.uk

Here, as with your example, there is no assertion that the d= domain  
is authoritative for some sub-domain.

versus

... i=[email-masked] d=co.uk

Currently this is permitted in the base draft which indicates the  
parent domain is authoritative for sub-domains.

Assume co.uk included DNS entries to support an MTA that handle  
messages with email-addresses:

<local-part>@co.uk

where their signature might normally contain:

... i=[email-masked] d=co.uk

or perhaps just

... d=co.uk

With the (baseless) assertion that any parent domain is authoritative  
for any sub-domain, their MTA systems might be mercilessly attacked  
until compromised in a number of ways.  Once accomplished, bad-actors  
could then spoof messages with any email-addresses that contained  
*.co.uk when parent signing is considered a means to verify sub- 
domain email-addresses (to get the gold-star annotation perhaps).    
Once bad-actors compromise just one key held at co.uk, the impact of  
this breach extends well beyond the co.uk domain.  By not permitting  
the assertion allowing any parent domain to be authoritative for sub- 
domain email-addresses, any breach would remain isolated to the  
domain where the key is located, as you suggested.  This requires a  
change to the draft.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 26 May 2006 18:24:27 -0700

>parent domain is authoritative for sub-domains.

This is absurd. Under which scenario would a signer in 
some-domain.co.uk possibly put d=co.uk in their signature?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 26 May 2006 18:41:00 -0700 (PDT)

On Fri, 26 May 2006, Paul Hoffman wrote:

>> Currently this is permitted in the base draft which indicates the parent 
>> domain is authoritative for sub-domains.
>
> This is absurd. Under which scenario would a signer in some-domain.co.uk 
> possibly put d=co.uk in their signature?

You did not fraze it right. They can obviously put it in, the signature
would just not be valid unless they have access to key of their parent
domain.
 								  V---V
What should be explained is that parent domain is authoritive for users
in its own and/or child domains when such users have access to full keys
(private and public) with public part published by the parent domain.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 May 2006 21:43:30 -0700

Paul Hoffman wrote:
> This is absurd. 

Quite possibly. In fact I am not understand why this sub-thread is being 
pursued, unless there is some support for the concern that I've missed.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Sat, 27 May 2006 07:24:01 -0700

> some-domain.co.uk possibly put d=co.uk in their signature?

If a bad-actor compromised a system handling the private key half of the
published key at d=co.uk, or got lucky cracking the key with a massive
bot-net or specialized hardware, then they would be able to generate
messages with email-addresses annotated as verified for _all_ of
*.co.uk.  Compromising a key high in the hierarchy, per the current
draft, would have a huge pay-off when spoofing messages.

By not allowing this unconfirmed assertion that the "parent is always
authoritative for email-addresses within sub-domains" removes any
special concern that exists with regard to MTA security at some higher
level. Remove this baseless assertion and then security can be
strengthened according to the need at the level being verified.

-Doug

---

From: Steve Atkins <[email-masked]>
Date: Sat, 27 May 2006 07:38:29 -0700

> draft, would have a huge pay-off when spoofing messages.

Given that no mail is sent from co.uk why would there be such a
key, unless your supposed attacker had already compromised the
co.uk dns infrastructure?

This argument is well beyond absurd.

> strengthened according to the need at the level being verified.

I can see several good arguments against this feature, but they're all
based on complexity, not security.

Could we perhaps move on?

Cheers,
   Steve

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 27 May 2006 08:49:00 -0700

>draft, would have a huge pay-off when spoofing messages.

This is in the "movie-plot terrorism" realm.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Sat, 27 May 2006 09:59:28 -0700

> This is in the "movie-plot terrorism" realm.

What exactly is far-fetched?  DKIM keys and MTA use at the xLDs does not
currently appear to be an immediate concern, allowing this provision,
where any parent domain is assumed authoritative for all sub-domain
email-addresses, gives high-level domains a tremendous advantage over
other email service providers for outbound services.

A high-level domain could offer email-address validation for a broad
range of email-addresses.  There does not seem to be any prohibitions
regarding the use of outbound MTAs at xLDs, although there may be
practical reasons for this not being done today.  This provision
provides a market incentive for the undesired deployment of keys at
these levels.  The absurdity seems to be the authoritative assumption.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Sat, 27 May 2006 12:46:49 -0700

Douglas Otis wrote:

> until compromised in a number of ways.  

Would that be Ming the Mercilessly? The movie plot thickens.

       Mike

---

From: "John R Levine" <[email-masked]>
Date: 27 May 2006 22:41:34 -0400

> to DKIM keys within higher-level domains.

Too bad.  It's still a contract issue, not a technical issue.

> for what is a valid sub-domain email-address.

No matter how many times you say this, it's still not true.  Repeating it
another dozen times won't change anything, so please don't.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sat, 27 May 2006 20:26:10 -0700

> No matter how many times you say this, it's still not true.  

indeed.  which prompts the obvious question:  why are folks pursuing this.

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Mon, 29 May 2006 09:14:52 -0700

> indeed.  which prompts the obvious question:  why are folks pursuing this.

This was an attempt to discuss the parent signing issue. It would be
helpful to indicate specifics rather than arguing against the
discussion.

Steve Atkins raised the point that example co.uk does not currently
implement DKIM as to why such concern is unrealistic.  A financial
incentive might change this assumption, when allowing any parent to
validate the email-addresses of any sub-domain "as-if" authoritative.
In addition to being at the pinnacle of trust for domain delegations,
without any change in domain delegation, this entity would find
themselves at the pinnacle of trust for email-addresses as well.

Dave, from your response, are you suggesting that ggTLD, ccTLD, SLD,
operators should be considered authoritative for all email-addresses
within their domain?  Or are you suggesting these operations should be
precluded from publishing DKIM keys?

John Levine takes the position this is a contractual issue, presumably
between the regulatory bodies and the domain service operators.  John,
are you suggesting all future contracts should include a ban on
publishing DKIM keys at these levels?

Proponents desire key publishing simplification by employing what is
often an unrealistic mandate.  Most would regard this mandate absurd
when viewed from the perspective their TLD provider.  This provider is
now authoritative for whether an email-address within their domain is
valid?  The legal and possible security issues trump a publishing
simplification.

The assertion any parent is _always_ authoritative (without any
confirmation) for any sub-domain email-address, together with a lack of
any existing contractual obligations for domain operators, may mean once
a DKIM key is publish at a very high level, this key will be targeted
for attack.  Once one such key is compromised, the entire domain is
compromised.  One key failure causing a compromise cascade for all
sub-domains seems like a very poor design choice.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 May 2006 17:27:06 +0100

Does anyone else share Doug's belief that these are serious
problems? If so, please you speak up now.

If no-one does, then we do have a pretty clear WG consensus
IMO.

Stephen.

---

From: Eric Allman <[email-masked]>
Date: Mon, 29 May 2006 14:30:33 -0700

Amazing what can happen when you take a couple of days to work at 
your day job....

> An important argument in favor of parent signatures involves
> wildcard MXes.

John, I think you did a great job of summarizing a very important 
point.  (In fact, I think it goes beyond your example.)

Count me as a +1 for keeping the spec as-is.

eric

---

From: Barry Leiba <[email-masked]>
Date: Mon, 29 May 2006 23:07:46 -0400

> indeed.  which prompts the obvious question:  why are folks pursuing this.

And I think the thread has gone on long enough with enough participants 
for me to say that I see strong consensus that this particular concern 
is not shared.

This subtopic is closed.  Let's look at any other reasons to remove the 
parent-domain point.  Is there one?

--
Barry Leiba, DKIM Working Group Chair  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Mon, 29 May 2006 20:53:19 -0700

On May 29, 2006, at 8:07 PM, Barry Leiba wrote:

> And I think the thread has gone on long enough with enough  
> participants for me to say that I see strong consensus that this  
> particular concern is not shared.
>
> This subtopic is closed.  Let's look at any other reasons to remove  
> the parent-domain point.  Is there one?

It's ugly and it adds significant complexity in analysing the system,  
and some lesser spec and implementation complexity.

The only valid reason to require it, I think, is for the benefit of  
users who use wildcard MXes, to enable them to make up subdomains on- 
the-fly, and who send mail using from addresses in those subdomains.  
Given that DK puts its information to the left of the domain-cut it's  
unavoidable in that case. I don't know how widespread this usage of  
mail sent (not received) with domain parts that map onto wildcard  
MXes with arbitrary subdomains is. I suspect it doesn't actually happen.

I think that if it's used in other cases it will be a fairly strong  
sign of bad architectural design on the part of the sender, but  
there's nothing that obliges a sender to use this misfeature in those  
cases, and I don't see any security issues with it being supported,  
other than complexity.

It's an ugly wart, but I see more harm in arguing about it than  
implementing it.

Cheers,
   Steve

---

From: John Levine <[email-masked]>
Date: 30 May 2006 05:04:59 -0000

>MXes with arbitrary subdomains is. I suspect it doesn't actually happen.

Sure it does:

http://www.panix.com/help/plusaddr.html

I agree that it's more common to invent per-correspondent addresses to
subscribe to mailing lists, but then to get your message posted, or to
adjust your mailing list settings, you do have to be able to send mail
from that address.

All of the funky things that people do with tagged subaddresses map
directly onto subdomains set up like Panix's (user-tag@foo ->
[email-masked]) and I suspect we'll be seeing more of them rather than
less in the future.

I think I still see a certain amount of mail from places that let you
use a workstation cluster and put the workstation name into the return
address.  I suppose that the number of workstations in a cluster is
unlikely to be so large as to make the corresponding DNS zone
unwieldy, but up to now you could set up your wildcards appropriately
so you just plug in a new workstation and the mail works.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Tue, 30 May 2006 11:21:21 -0700

> the parent-domain point.  Is there one?

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,  
and AfricNIC 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 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 possible 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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 30 May 2006 13:27:43 -0700

On May 29, 2006, at 8:53 PM, Steve Atkins wrote:

> users who use wildcard MXes, to enable them to make up subdomains  
> on-the-fly, and who send mail using from addresses in those  
> subdomains.

The parent domain can still sign messages.  The question is whether a  
signing-domain should be precluded from linking with an email-address  
of a sub-domain.  This mechanism is intended to establish trust for  
an email-address via the signing-domain.  A verifier could create  
special policies for when an email-address is a sub-domain of the  
signing-domain, which may result in the same practical limitations as  
would excluding the use of this linking mechanism.  In general,  
reducing a profusion of right-hand-side names better establishes  
trust.  Precluding the use of wildcard MX records also reduces some  
concerns related to various attack scenarios.

If this i= provision is included, the informational RFC1591 should be  
updated.  By allowing a link to an email-address be fully independent  
of any domain delegation, TLD managers will be able to offer DKIM  
related services where keys for domains can be stored in a sub-domain  
directly below the TLD.  When one assumes the signing-domain  
establishes trust, keys at these locations might be considered elite  
property generating substantial revenue.  If it become a common  
practice for TLD managers to offer DKIM key services, security  
becomes far more critical due to a catastrophic failure mode.

-Doug