Subject: [ietf-dkim] Underscore considerations

From: Jim Fenton <[email-masked]>
Date: Thu, 08 Jun 2006 16:35:18 -0700

There was some discussion in today's Jabber about whether the use of the
underscore character in the i= field of a signature creates a new
vulnerability.  This originated with the following suggested text in
issue 1285 (https://rt.psg.com/index.html?q=1285):

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

First of all, I don't see any reason why the _domainkey subdomain
couldn't be delegated.  In fact, we use the delegation of _domainkey as
an example of how key management could be done when using an outsourced
email provider.

Let's try to construct the problem case:  Suppose someone managed to
register _domainkey.com.  They could then publish keys in that domain,
and sign arbitrary messages on behalf of .com.  That's obviously a Bad
Thing.

The piece I'm missing is if it's even possible to register a domain
beginning with an underscore, or whether there are specific rules
preventing that.  The delegation rule I cited above (that it is
possible) applies to DNS, but I don't know if other policies (ICANN,
perhaps) restrict that further with respect to domain registration.  I
surfed a bit around ICANN but didn't find anything relevant.  Does
anyone know?

So perhaps we need something like the following text:  "Domains MUST NOT
delegate the _domainkey subdomain unless they have the intent to allow
the delegatee to sign messages on behalf of the entire domain or any of
its subdomains."

I don't see any other problem with the underscore character in i=
values, or in domain names.

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

---

From: Douglas Otis <[email-masked]>
Date: Thu, 8 Jun 2006 16:56:39 -0700

> an example of how key management could be done when using an  

In the revision, this was clarified. See:
http://mipassoc.org/pipermail/ietf-dkim/2006q2/003830.html

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

> and sign arbitrary messages on behalf of .com.  That's obviously a Bad

The Registry Operator Functional Specification Agreement normally  
prohibits this character.  A registered name must begin with an alpha  
character.  The rules governing the SLD may differ and some providers  
may inject their own stuff as an alternative root.

> preventing that.

The rules on per Registry operation per tld.  The many that I have  
examined all preclude registering a domain name that does not begin  
with an alpha character.  Obviously, the wildcard trick by Verisign  
proved that anything could be synthesized.  The correction to this  
problem was to stop that activity from what I could conclude.

>   The delegation rule I cited above (that it is

Is I said, you need to look into each Registry Operator Functional  
Specification Agreement.

> the delegatee to sign messages on behalf of the entire domain or  

I'll post my summary and get your feedback.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Jun 2006 17:00:44 -0700

>and sign arbitrary messages on behalf of .com.  That's obviously a Bad

Er, why? It is only bad if someone signs messages with "d=com", which 
is unlikely.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 8 Jun 2006 17:07:14 -0700

On Jun 8, 2006, at 5:00 PM, Paul Hoffman wrote:

> Er, why? It is only bad if someone signs messages with "d=com",  
> which is unlikely.

Assume that a recipient expects to see the email-address validation  
annotation.  A bad actor that has obtained or compromised a key at  
this location could then sign messages and recipients could see all  
the email-address using *.com annotated as having be validated.  This  
validation, as currently defined in DKIM, is to be accepted.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Thu, 08 Jun 2006 17:08:03 -0700

>surfed a bit around ICANN but didn't find anything relevant.  Does
Even if you could, and even if a registrar were boneheaded enough to shoot
their own foot, how hard could it possibly be for a DKIM verifier to 
enumerate
the TLD's and not accept selectors from that set of blacklisted _domainkey
delegations? Am I missing something?

       Mike

---

From: Jim Fenton <[email-masked]>
Date: Thu, 08 Jun 2006 17:14:32 -0700

> Er, why? It is only bad if someone signs messages with "d=com", which
It would be likely if it was a Bad Actor that registered the domain. I
meant to say "a bad actor" rather than "someone".

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Thu, 08 Jun 2006 17:22:06 -0700

Paul Hoffman wrote:
> Er, why? It is only bad if someone signs messages with "d=com", which is
> unlikely.

By virtue of its delegation model, DNS creates a hierarchy of trust
relationships across administrative boundaries.  When crossing a trust boundary,
as one traverses a branch of the DNS, there are various opportunities for abuse
by the parent.

The only thing that might be considered "interesting" about this, with respect
to DKIM, is that DKIM is specifically (and exclusively) a security mechanism.
That heightens both sensitivity to abuse issues and perhaps makes it a bit more
attractive as a target.

It might not be silly of us to have a paragraph that says something along these
lines, in the Security Considerations section. However I see nothing that makes
it any sort of requirement.

d/

-- 

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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 08 Jun 2006 17:40:09 -0700

Jim Fenton wrote:

>Michael Thomas wrote:
>It's not just the TLDs that are problems here:  It could be .co.uk, or
>even .sanjose.ca.us (not meaning to pick on any particular registrars;
>these are just examples)
>  
>
Right, but what I'm wondering is how hard this would be to mitigate in real
life. Maybe it would be hard to get _every_ top level delegation cut, 
but the
delegation cuts where _real_ damage could be done seems like a pretty 
small set. If
I did nothing more than say I won't accept selectors from _domainkey.com,
it would seem to me that in one swell-foop that I'd have cut off the 
single most
potentially lucrative attack vector. And so on.

But like I said, this is even assuming that you'd have boneheaded registrars
intent on not only shooting themselves in the foot, but continuing to shoot
themselves in the foot by not killing the bogus domain. That doesn't seem
especially credible to me.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 8 Jun 2006 17:46:35 -0700

On Jun 8, 2006, at 5:08 PM, Michael Thomas wrote:

> their own foot, how hard could it possibly be for a DKIM verifier  
> to enumerate

Imagine a large corporation issues private keys to everyone under  
their highest level domain.  Why? Because it is easy, which is the  
justification made for the 'i=' subdomain feature in the first place.

These individual users can specify any subdomain where perhaps their  
localpart is restricted and still have it annotated as verified.  Now  
some of these keys are captured by the new worm affecting some  
program.  Spammers can now send valid email messages using billions  
of different email-addresses all thanks to the convenience provided  
for transmitting messages with the i=@subdomain feature.

This allows any of the following email-addresses to be validated:
Joe Blow <[email-masked]>
President and CEO <[email-masked]>
Directory of Finance <[email-masked]>
Babe <[email-masked]>
Sam Spade <[email-masked]>
Julie <[email-masked]>
JC <[email-masked]>
Director <[email-masked]>
Accounting <[email-masked]>

The recipients of these spams will need to look at the key selector  
to block the onslaught and still communicate with big-company.  It  
would not be simple to block by email-address, thank you very much.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Thu, 08 Jun 2006 17:51:46 -0700

> for transmitting messages with the i=@subdomain feature.

Until the selector is revoked by big-domain. This is a non-issue, and is 
certainly
not the issue under discussion.

       Mike

---

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

On Jun 8, 2006, at 5:51 PM, Michael Thomas wrote:

>>> their own foot, how hard could it possibly be for a DKIM  
>>> verifier  to enumerate
>> their highest level domain.  Why? Because it is easy, which is  
>> the  justification made for the 'i=' subdomain feature in the  
>> first place.
>>
>> These individual users can specify any subdomain where perhaps  
>> their  localpart is restricted and still have it annotated as  
>> verified.  Now  some of these keys are captured by the new worm  
>> affecting some  program.  Spammers can now send valid email  
>> messages using billions  of different email-addresses all thanks  
>> to the convenience provided  for transmitting messages with the  
>> i=@subdomain feature.
>
> Until the selector is revoked by big-domain. This is a non-issue,  
> and is certainly

But this is the issue being discussed.  These are serious security  
concerns.  There is zero containment of local-part namespace between  
any subdomains.  This too becomes a serious concern and is one of the  
problems created.  Even if a higher level domain wanted to do DKIM  
safely, the MUA signing feature would be a disaster as a result of  
this dubious feature.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Jun 2006 18:45:27 -0700

At 5:57 PM -0700 6/8/06, Douglas Otis wrote:
>any subdomains.  This too becomes a serious concern and is one of 
>the problems created.  Even if a higher level domain wanted to do 
>DKIM safely, the MUA signing feature would be a disaster as a result 
>of this dubious feature.

The WG already accepted the feature after active discussion. Trying 
to use the Security Considerations section to make the feature seem 
"dubious" feels like an attack on the WG consensus process.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Thu, 08 Jun 2006 17:21:55 -0700

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Thu, 08 Jun 2006 18:56:08 -0700

Paul Hoffman wrote:
> The WG already accepted the feature after active discussion. Trying to
> use the Security Considerations section to make the feature seem

another view is that it is merely an attempt at some humor, since it is
difficult to imagine taking the concern seriously.

d/

-- 

  Dave Crocker

---

From: SM <[email-masked]>
Date: Thu, 08 Jun 2006 20:53:48 -0700

Hi Jim,
>and sign arbitrary messages on behalf of .com.  That's obviously a Bad

Domain names are limited to alphabetic characters, digits and hyphen.

Regards,
-sm

---

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

> difficult to imagine taking the concern seriously.

A private key intended for use at an MUA can not be constrained to
validate only a specific email-address domain as a direct result of the
'i=@subdomain' feature.  Any use of a '_domainkey' subdomain by a higher
level domain therefore requires additional considerations.  Would you
suggest this may require avoiding the use of an MUA based approach?

Spoofing should be a problem addressed by DKIM.  This is significantly
jeopardized by an 'i=' subdomain convenience extensively employed by
spammers to obfuscate their domain with unverified and imaginary
subdomains within the signed 'i=' parameter.  These unverified
components of the email-address domain weaken the concept that an
email-address is validated by DKIM.  When the domain of the
email-address is uncertain, so is the local-part, irrespective of a 'g='
parameter within the key.

If this 'i=' subdomain feature is retained, then extensively warn about
what can go wrong when just trusting some higher domain to act beyond
existing delegation obligations.  Do not naively depend upon these
details being in favor of the DKIM implementor.  These issues need far
better clarification.

The latest Security Consideration section:
http://mipassoc.org/pipermail/ietf-dkim/2006q2/003830.html

did clarify that most Registry Operators are normally prohibited from
registering a name without a leading alpha character, but that is not
the end of the story.  There are also cases to consider unrelated to how
DNS works with regard to delegation.  In the case of DKIM, zones not
delegated to the email-address domain owner can dramatically affect the
operation of their email domain without having violated any delegation
arrangements.

Of course, this concern depends upon how seriously email-address
verification is taken.  Email-address annotation will be hard pressed to
clarify which sections of an email-address domain have actually been
verified.

DKIM-Signature: 
  s=sales02; i=[email-masked]; d=big-company.com; ...

 <[email-masked]> 

This annotation could mean accounts might be a fictitious domain, but
then there is internationalization to consider.  Email filtering will
become more complex handling possible synthetic camouflage when needing
to block specific abusive accounts.  While messages sent to abuse@ might
be used to get the key eventually withdrawn, an immediate solution is
also needed when communication with big-company.com is to be retained.

-Doug

---

From: <[email-masked]>
Date: Fri, 9 Jun 2006 08:23:07 -0400

Just want to clarify
You want to ensure that wildcards and i,g tags can delimit subdomains,
is that correct?

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Douglas Otis
Sent: Thursday, June 08, 2006 8:07 PM
To: Paul Hoffman
Cc: IETF-DKIM
Subject: Re: [ietf-dkim] Underscore considerations

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 09 Jun 2006 07:07:16 -0700

> You want to ensure that wildcards and i,g tags can delimit subdomains,

The concern about conveying what is a validated email-address has little
to do with MX records using a wildcard.  This only relates to why did
this become a problem.  Allowing any subdomain within the i= parameter
is to accommodate a wildcard MX technique.  This is to reduce the burden
on the transmitter.  By requiring a key be referenced from the
email-address domain, this provides a means to validate the domain,
while also limiting the scope of the key.

Without a means to qualify whether this email-address's subdomains have
been properly synthesized (by an MUA application), less assurance of the
email-address becomes possible.  This increases the burden upon the
receiver.  It also means blocking, when there is a problem, can not
depend upon the validated email-address obtained from DKIM.  Blocking at
the signing-domain may be problematic when this causes extensive
collateral blocking of desired messages.  Ether the recipient adopts
local-part@[*.]domain filters or uses selectors, while prior tools could
have otherwise been used.  As a result of the allowance, email-address
validation becomes far less meaningful.

> the email-address using *.com annotated as having been validated.
> This validation, as currently defined in DKIM, is to be accepted.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 9 Jun 2006 07:32:23 -0700

>Domain names are limited to alphabetic characters, digits and hyphen.

No, *host names* are restricted to alphabetic characters, digits and 
hyphen. This has been discussed, ad nauseum, for decades.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 09 Jun 2006 15:34:48 +0100

Doug,

Your first paragraph below is impossible for me, and I bet, others,
to understand. If you're not clear you'll be ignored, most likely.
Sorry to call this out on the list, but this is far from being the
first time.

So: use fewer words!

Stephen.

---

From: Steve Atkins <[email-masked]>
Date: Fri, 9 Jun 2006 08:02:40 -0700

On Jun 9, 2006, at 7:32 AM, Paul Hoffman wrote:

> No, *host names* are restricted to alphabetic characters, digits  
> and hyphen. This has been discussed, ad nauseum, for decades.

No, *host names* are scarcely restricted at all. You may wish it were  
otherwise, but it's not the case. In particular, underscores are  
downright common in hostnames, and most DNS servers don't put any  
constraints on them. There are RFC requirements on them, sure, but  
most people naming hosts aren't aware of them, they're not enforced  
by software and nothing bad happens when you violate them.

About the only thing you can rely on is that most (all?) registries  
enforce those character restrictions in domains registered with them.  
Which, fortunately, is enough to avoid the _domainkey.com "problem".

Cheers,
   Steve

---

From: Eliot Lear <[email-masked]>
Date: Fri, 09 Jun 2006 17:25:01 +0200

Steve Atkins wrote:
> most people naming hosts aren't aware of them, they're not enforced by
> software and nothing bad happens when you violate them.
>

People do all sorts of dumb things.  Shall we document them all?

Eliot

---

From: Steve Atkins <[email-masked]>
Date: Fri, 9 Jun 2006 08:30:25 -0700

> People do all sorts of dumb things.  Shall we document them all?

No. But nor shall we rely on them not doing them as reason to dismiss
a supposed "security" issue. I can think of dozens of other reasons to
do so, but "people don't put underscores in hostnames" isn't one.

Cheers,
   Steve

---

From: John Levine <[email-masked]>
Date: 9 Jun 2006 18:27:53 -0000

>enforce those character restrictions in domains registered with them.  

I just checked, none of the domain I register via Tucows will accept a
name that starts with an underscore, although of course there are lots
of other TLDs and lots of delegation points below the TLD.

So anyway, as I said the first time this came up, this is a
contractual issue between a domain and its superdomains, and is merely
one example of the general rule that if your superdomain is
sufficiently hostile or incompetent, you lose.

Since that problem affects every use of the DNS, I don't see any point
in us documenting it here.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Fri, 9 Jun 2006 13:27:45 -0700

> Sorry to call this out on the list, but this is far from being the  

I'll try to explain it using examples.

>> The concern about conveying what is a validated email-address has  
>> little to do with MX records using a wildcard.

This was answering a question about delimiting wildcards, which was  
understood as delimiting an email-address that, upon delivery,  
references a wildcard MX.

>> This only relates to why did this become a problem.  Allowing any  
>> subdomain within the i= parameter is to accommodate a wildcard MX  
>> technique.

While any domain can sign a message where the key is located by the  
'd=' parameter, some signing domains also, as an option, want an  
email-address contained within the message to be annotated as  
"validated", or to display the "signing address."  As Dave Crocker  
correctly suggested "signing address" is not technically correct.  A  
more accurate term could have been email-address "validation  
template", but that does not sound as official. : (

>> This is to reduce the burden on the transmitter.

This (meaning the 'i=@subdomain' feature) is to consolidate the  
number of DNS records within a common location at a higher level  
subdomain.  The transmitter wants their email-addresses annotated as  
"validated" but also doesn't want to bother publishing a key  
referenced from the email-address domain.

>> By requiring a key be referenced from the email-address domain,  
>> this provides a means to validate the domain, while also limiting  
>> the scope of the key.

A requirement that a key be referenced from the email-address domain  
when this email-address is to be "validated" would mean:

	[email-masked]

requires a signature of:

   DKIM-Signature:
     s=select; i=joe; d=subdomain.domain.tld;

By not having this requirement means the scope or the range of  
possible email-address subdomains a key can validate would be unlimited.

	[email-masked]

allows a signature of:

   DKIM-Signature:
     s=select; i=[email-masked]; d=domain.tld;

where the same key is free to also "validate" an email-address of:

	[email-masked]

   DKIM-Signature:
     s=select; i=[email-masked]; d=domain.tld;

or
	[email-masked]

   DKIM-Signature:
     s=select; i=[email-masked]; d=domain.tld;

where 'another' or 'any-subdomain' is never validated as being real,  
and yet DKIM declares [email-masked]' and  
[email-masked]' as "validated."

Of course, this lack of restriction requires that precautions be  
exercised, as a compromised or misused key may affect _all_ subdomains.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 09 Jun 2006 21:41:34 +0100

Douglas Otis wrote:
>> Your first paragraph below is impossible for me, and I bet, others, to 
>> understand. If you're not clear you'll be ignored, most likely. Sorry 
>> to call this out on the list, but this is far from being the first time.
> 

Pity none of them involved an underscore.

Your examples seem to pertain to a resolved issue, so I'm happy to
let this thread die.

Stephen.

---

From: Jim Fenton <[email-masked]>
Date: Fri, 09 Jun 2006 13:59:50 -0700

Bill,

I'm not sure I understand the question.  The g= tag (in the key record)
only has to do with the local-part of the address, and can be
wildcarded.  There is no definition of wildcards in the i= address.  The
only 'wildcarding' that exists with respect to subdomains is that
implied by the fact that d= can be a parent domain of i=, so a parent
domain (say, example.com) can sign for a subdomain (*.example.com or
even *.*.example.com, etc.).

Or did I mis-interpret your question?

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Fri, 09 Jun 2006 14:10:42 -0700

Let me see if I understand Doug well enough to boil this down to a small
example:

Suppose [email-masked] is a outsourced benefits provider which
needs to sign messages in order to send them to clients at example.com
without making them look spoofed.  So the domain administrator of
benefits.com delegates the use of a keypair by publishing a key record
in _domainkey.example.com, with g=benefits.

This gives the holder of the private key the ability to sign messages
for [email-masked], which might be a different provider, in
addition to the intended address.

I can see where this might not be desired.  The fix for this that I
would suggest would be to put something in the key record saying that
the key can't sign for subdomains.  Is this worth doing?

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 09 Jun 2006 22:23:22 +0100

Don't you very quickly run into policy considerations once you
start down that route? In your example, if I want the key to be
ok for foo.example.com during working hours and bar.example.com
for 24 hours.

So another approach would be to punt to ssp if this is a real
concern (and there are those arguing it isn't),

S.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 09 Jun 2006 14:53:52 -0700

>the key can't sign for subdomains.  Is this worth doing?
Oh. Well, at least this isn't trying to make the DNS into something that
it isn't. I can see some merit to this, as it's a parent delegation control
which constrains in a similar way as g= constrains the local part. Shall
we burn a new flag in t=? :)

       Mike

---

From: Jim Fenton <[email-masked]>
Date: Fri, 09 Jun 2006 14:58:17 -0700

I don't see this as a policy issue.  It really has to do with
determining whether a given signature is valid or invalid.  If the
signature is valid, and is a first party signature, we might not even
need to consult policy (depending on what direction the SSP discussion
takes, of course...).

-Jim

---

From: John Levine <[email-masked]>
Date: 9 Jun 2006 22:31:56 -0000

>the key can't sign for subdomains.  Is this worth doing?

Heck, no.  This is yet another technical solution to a non-technical
problem.  The company tells its provider "use this key to send mail
about our benefits program from [email-masked]" If they misuse
it, they revoke the validation key and say "you're fired."

If their job is to send mail with a return address of
[email-masked] with contents saying "your claim is denied", what
would you do if the contents instead said Hot Nude Teen Babes?  Why
should that be any different from what you'd do if they used an
unauthorized From: address?  Why do you want to make a special case
for one particular kind of misuse of a signing key?

R's,
John

PS: If you think this means that I don't find i= to be very useful,
you're right, but it seems harmless enough that I see no reason to
take it out.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 9 Jun 2006 15:45:45 -0700

> Pity none of them involved an underscore.

The terminology 'key is "referenced" or "located"' use a '_domainkey'  
subdomain.

                                      . <- root
                                 <tld>. <- <tld>
                          <name>.<tld>. <- registered <name>
         <sel>._domainkey.<name>.<tld>. <- key @ <name>.<tld>
<sel>._domainkey.<any-s>.<name>.<tld>. <- key @ <any-s>.<name>.<tld>

<tld>   = any top level domain
<name>  = any registered domain or second level domain
<any-s> = any subdomain or sequence of subdomains
<sel>   = label or labels found within the 's=' parameter

-Doug

---

From: John Levine <[email-masked]>
Date: 10 Jun 2006 00:15:40 -0000

>the key can't sign for subdomains.  Is this worth doing?

Hi, I'm back with another proposal that completely contradicts my
previous message.

I observe that generally speaking, the mailbox [email-masked] is not
the same as [email-masked].  And even if those two happen to be
the same, they're probably not the same as [email-masked].
(There was an era when it was common to configure a cluster of
workstations to put the workstation name as a subdomain in your
outgoing return address, but that era only existed because of a widely
used but poorly configured default sendmail.cf and it ended about a
decade ago.)

So my suggestion is to leave the key and signature formats alone, but
to change the interpretation accordingly.

In section 6.1.2, the verification process, add a sentence to step 6:

  If the "g=" tag in the public key does not match the local part of
  the "i=" tag on the message signature, the verifier MUST ignore the
  key record and return PERMFAIL (inapplicable key). If the local part
  of the "i=" tag on the message signature is not present, the g= tag
  must be * (valid for all addresses in the domain) or not present
  (which defaults to *), otherwise the verifier MUST ignore the key
  record and return PERMFAIL (inapplicable key).

(new part)

  If the "g=" tag in the public key is present and is anything other
  than *, and the domains in the "i=" and "n=" tags in the signature
  are not identical, the verifier MUST ignore the key record and
  return PERMFAIL (inapplicable key).

(end new part)

  Other than these tests, verifiers SHOULD NOT treat a message signed
  with a key record having a g= tag any differently than one without;
  in particular, verifiers SHOULD NOT prefer messages that seem to
  have an individual signature by virtue of a g= tag vs. a domain
  signature.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Fri, 9 Jun 2006 18:22:31 -0700

>   return PERMFAIL (inapplicable key).

This transforms the key's n= (note) into an i= template.  Rather than  
conditioned upon 'g=', Why not always have the 'n=' represent an 'i='  
template?  Or rather perhaps this feature could even use an 'i=' tag  
in the key.

Can you help me understand why is really needed?

These i= and g= mechanisms are about validating an email-address, and  
are not about signing the message.  You have already indicated that  
for the majority of email that you will be signing on the behalf of  
others, email-address validation is not important.  I see nothing  
wrong with this approach.

Rather than increasing the complexity of these mechanisms intended to  
validate the email-address by introducing virtual subdomains over  
signing domains, why not simply require the key to be located at the  
same level as the email-address domain being validated?

When playing games with local-part tags and virtual subdomains, does  
this odd corner case really justify all this?  The 'i=' construct  
would be greatly simplified by not including the '@' symbol and  
labels compared against the 'd=' parameter.  There would be no  
concerns about what might happen within a higher level '_domainkey"  
subdomain.  There would be no need to draw up extra contracts or  
establish more additional regulations on domain managers and service  
providers.  The information found within the key and signature would  
also be reduced.

With this complex scheme, instead of publishing a key at the domain  
of the email-address, these domains must be repeated within the 'i='  
parameter (and 'n=') for each message.  The alternative would be a  
one time act of publishing a key.  The one time act reduces the  
amount of repeated information exchanged perhaps millions of times over.

This would also mean when an email-address has been validated, there  
is no question in the mind of the recipient which domain is  
responsible for having asserted the validation.  When there are  
virtual domains include, the recipient must now guess or check unseen  
headers.  When a key goes astray, blocking is afforded greater  
granularity at the signing domain.  Filtering the local-part would  
not need to utilize information now hidden within the key.  Life gets  
so much simpler not allowing this "convenience."

-Doug

---

From: <[email-masked]>
Date: Sun, 11 Jun 2006 00:28:54 -0400

At this point I tend to support Doug's position that we "allow" wildcard entries on both sides of the "@" to delimit abuse.
hanks,
Bill

-----Original Message-----
From: [email-masked] on behalf of Douglas Otis
Sent: Fri 6/9/2006 4:27 PM
To: Stephen Farrell
Cc: [email-masked]
Subject: Re: [ietf-dkim] Underscore considerations

	[email-masked]

requires a signature of:

   DKIM-Signature:

	[email-masked]

allows a signature of:

   DKIM-Signature:

   DKIM-Signature:

or

   DKIM-Signature:

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Sun, 11 Jun 2006 15:36:59 -0700

On Sun, 2006-06-11 at 00:28 -0400, [email-masked] wrote:

> At this point I tend to support Doug's position that we "allow"
> wildcard entries on both sides of the "@" to delimit abuse.

I assume this refers to the base-02 //g= template suggestion:
http://mipassoc.org/pipermail/ietf-dkim/2006q2/003762.html

This proposal differs from John's by not requiring an additional tag be
included to conditionally extend constraints of the 'g=' tag.

The 'g=' tag syntax is extended by allowing inclusion of the '@' symbol,
and the '_' character representing the domain containing the
"_domainkey" label.

Wildcarding is then allowed on both sides of the '@' symbol for
expansion of the template to match an email-address being annotated as
being assured as "properly" used by the signing domain.  Examples might
include:

"user*",
Matching user[-stuff]@[any-subdomain.]signing-domain.tld

"user@*"
Matching user@[any-subdomain.]signing-domain.tld

"*@_"
Matching [any-user]@signing-domain.tld

"*@sub-domain_"
Matching [any-user]@sub-domain.signing-domain.tld

"*@*sub-domain_"
Matching [any-user]@[any-other.]sub-domain.signing-domain.tld

----
Caveat

Use of templates for validating email-addresses, especially within the
right-hand portion of the email-address, reduces security.  The intent
is to convey an explicit assurance made by the signing domain.  When an
assurance of proper email-address use is conveyed by a match to a
partial template within the 'i=' parameter, email-address annotations
must also be confined to headers contained within the message signature.

When sub-domains are included within the 'i=' parameter, domain specific
constraints are hidden by being present only within the key.  A log of a
key related sub-domain qualification will likely not be recorded.  It
should also be noted that the 'g=' template information, although
critical to security, is neither signed nor logged by way of captured
signature header information and verification results.

Use of email-address templates offering expansions within both left and
right hand portions of the email-address offer little in the way of
security.  It is likely 'i=' or 'g=' use of the '@' and '_' expansions
will be problematic with respect to consistent validation annotations as
there are multiple methods to convey similar restrictions.

A simplified alternative:

A generally safer and more conservative approach would only allow either
the complete local-part or nothing to appear in either of these
parameters, and therefore disallow use of virtual sub-domains.  When an
MTA wishes to employ a common private key for signing all sub-domains,
where email-address within these sub-domains are also to be validated, a
copy of the public key is published at each of these validated
sub-domains.

The impact of this simplification:

A compromised key will never affect the validation of email-addresses
using sub-domains below where the key is published.  The domain
validating the email-address will always be obvious to the recipient.  A
compromised key can also be blocked by an entry of a single address in a
simple form.  The 'g=' parameter can return to being compatible with
that of DomainKeys. 

-Doug