Subject: [ietf-dkim] base-04 //inverting key t= 's'ub-domain flag

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Jul 2006 12:35:14 -0700

A possible use of DKIM is to validate email-addresses through a  
comparison against a "signing identity".  An extension to this  
feature allows simple inclusion of subdomains within the signing  
identity that are independent of the signing domain from where the  
key is referenced.  This extension could be seen as having problems  
analogous to that of validating cookies within sub-domains.  The  
related issue with cookies is discussed within dns-ops.

See:
http://www.ietf.org/internet-drafts/draft-pettersen-dns-cookie- 
validate-00.txt

In addition to changing the default to being a "safe" mode of  
operation, a safety or administrative concern may prompt for this  
feature to be removed in the final draft version.  By not recognizing  
the "s" flag through removal of its description, this extension could  
be disabled only when the meaning of the "s" flag and associated  
default is inverted.

To gracefully allow removal of this feature, should that become  
required, the sense of the "s" flag and the corresponding defaults  
should be inverted as follows:

,---
|3.8  Signing by Parent Domains
|
|In some circumstances, it is desirable for a domain to apply a
|signature on behalf of any of its subdomains without the need to
|maintain separate selectors (key records) in each subdomain.  By
|default, private keys corresponding to key records can be used to
|sign messages for any subdomain of the domain in which they reside,
|e.g., a key record for the domain example.com can be used to verify
|messages where the signing identity (i= tag of the signature) is
|sub.example.com, or even sub1.sub2.example.com.  In order to limit
|the capability of such keys when this is not intended, the "s" flag
|may be set in the t= tag of the key record to constrain the validity
|of the record to exactly the domain of the signing identity.  If the
|referenced key record contains the "s" flag as part of the t= tag,
|the domain of the signing identity (i= flag) MUST be the same as that
|of the d= domain.  If this flag is absent, the domain of the signing
|identity MUST be the same as, or a subdomain of, the d= domain.  Key
|records which are not intended for use with subdomains SHOULD specify
|the "s" flag in the t= tag.
'---

change to:

: In some circumstances, it is desirable for a domain to apply a
: signature on behalf of signing identities (i= tag in the DKIM
: signature field) within subdomains of the signing domain (d=
: tag in the DKIM signature field) without the need to maintain
: separate key records referenced from each subdomain.  Without the
: referenced key record containing the "s" flag as part of the t=
: tag, the domain of the signing identity MUST be the same as that
: of signing domain.  By default, private keys corresponding to key
: records will not provide valid signatures for messages having a
: signing identity within a subdomain of the signing domain.  When
: required, the "s" flag may be set in the t= tag of the key record
: to enable such keys to provide valid signatures for signing
: identities within subdomains of the signing domain, e.g., a key
: record would permit a valid signature for the signing domain
: example.com when the signing identity is sub.example.com, or even
: sub1.sub2.example.com.  If this "s" flag is present, the domain of
: the signing identity MUST be the same as, or a subdomain of, the
: signing domain. Key records which are not intended for signing
: identities within subdomains of the signing domain SHOULD NOT
: specify the "s" flag in the t= tag.

,---
| 3.6.1  Textual Representation
|...
| s   Any DKIM-Signature header fields using the "i=" tag MUST have
|     the same domain value on the right hand side of the "@" in
|     the "i=" tag and the value of the "d=" tag.  That is, the
|     "i=" domain MUST NOT be a subdomain of "d=".  Use of this
|      flag is RECOMMENDED unless subdomaining is required.
'---

change to:
: s   Without this flag being asserted, any DKIM-Signature header
:     field using the "i=" tag MUST have the same domain value on
:     the right hand side of the "@" in the "i=" tag as the value
:     of the "d=" tag.  Without this flag, the "i=" domain MUST NOT
:     be a subdomain of "d=".  This flag should only be asserted
:     when subdomains are required within the DKIM signature field
:     "i=" value that do not appear within the "d=" value.

Also note that section 3.8 incorrectly uses (i= flag) instead of (i=  
tag).

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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 19 Jul 2006 13:40:02 -0700

-1

First of all this would break backward compatibility with the existing
DK records. Second, I don't see what the problem is with the current
sense: if you don't like subdomains, by all means set t=s. And I can
tell you from first hand experience as somebody who has deployed
this: the subdomain signing feature is definitely being used, so the
comment on draft standard does not apply.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Jul 2006 15:06:51 -0700

On Jul 19, 2006, at 1:40 PM, Michael Thomas wrote:

> -1
>
> First of all this would break backward compatibility with the  
> existing DK records. Second, I don't see what the problem is with  
> the current sense: if you don't like subdomains, by all means set  
> t=s. And I can tell you from first hand experience as somebody who  
> has deployed this: the subdomain signing feature is definitely  
> being used, so the comment on draft standard does not apply.

Inverting the meaning of the "s" flag is compatible with a DomainKeys  
record, as the DomainKeys signature does not include a separate  
signing identity nor an "s" flag. The DKIM signature version can also  
differentiate between pre-draft versions that lack provisions for  
constraining valid signatures for subdomains identities.  This issue  
matters during verification where an older DKIM verifier will not  
correctly interpret the "s" flag regardless.  For those currently  
signing subdomain identities to this draft, the "s" flag should be  
added.  Not having the "s" flag should default to a safer and  
constrained mode of operation.  Removing the subdomain identity  
constraint in exceptional cases should involve the minor effort of  
adding the optional (not recommended) "s" flag.  Hopefully, in the  
majority of cases, the "s" flag is not included and perhaps not  
acceptable.  Just as with the l= tag, ignoring it does the right  
thing.  The same should be true with the "s" flag.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Wed, 19 Jul 2006 15:42:48 -0700

Douglas Otis wrote:

>> has deployed this: the subdomain signing feature is definitely  being 
>> used, so the comment on draft standard does not apply.
>
>
> signing identity nor an "s" flag. 

Note I said "backward compatible"; this proposal is not. A DK record 
deployed now
signs for all of its subdomains. Your proposal would not only invalidate 
working
implementations now, but it would require sites to go on a wild goose 
chase to
figure out all of the hosts/subdomains are sending mail. For our 
situation, that would
make a feasible deployment an infeasible deployment overnight.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Jul 2006 16:38:21 -0700

On Jul 19, 2006, at 3:42 PM, Michael Thomas wrote:

>>> existing DK records. Second, I don't see what the problem is  
>>> with  the current sense: if you don't like subdomains, by all  
>>> means set  t=s. And I can tell you from first hand experience as  
>>> somebody who  has deployed this: the subdomain signing feature is  
>>> definitely  being used, so the comment on draft standard does not  
>>> apply.
>>
>>
>> Inverting the meaning of the "s" flag is compatible with a  
>> DomainKeys  record, as the DomainKeys signature does not include a  
>> separate  signing identity nor an "s" flag.
>
> Note I said "backward compatible"; this proposal is not.

It depends upon what default is desired when the "s" flag is not  
specified.

> A DK record deployed now signs for all of its subdomains.

Currently, to restrict this key, a modification of the key is  
required.  When a restriction is the desired default, as it should be  
in most cases, no additional effort is needed by inverting the  
meaning of the "s" flag.

> Your proposal would not only invalidate working implementations  
> now, but it would require sites to go on a wild goose chase to  
> figure out all of the hosts/subdomains are sending mail.

Requiring the "s" flag to sign subdomain identities would not  
invalidate working implementations.  A domain that commonly signs  
subdomains would add the "s" flag, provided they understand the  
ramifications of doing so.  Otherwise, the default mode without the  
"s" flag would remain the safer mode of operation.

> For our situation, that would make a feasible deployment an  
> infeasible deployment overnight.

For those signing subdomain identities, this would require adding the  
"s" flag and waiting for the RR TTL to expire, or perhaps simply  
rolling the key.  Only those that understand the ramifications of  
removing the subdomain constraint should do so only when this is  
required.  It is far less safe to default removal of a constraint.   
In your case, it may mean some added effort, but no effort to  
establish the safer mode.  If this feature becomes obsoleted,  
ignoring and not using the "s" flag does the right thing.  Otherwise  
the "s" flag may resemble a vestigial tail.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Wed, 19 Jul 2006 17:06:06 -0700

Douglas Otis wrote:

>>>> t=s. And I can tell you from first hand experience as  somebody 
>>>> who  has deployed this: the subdomain signing feature is  

Wrong. DK records sign for all subdomains. That is the current semantic. 
Changing
that semantic is not backward compatible. Your desire does not get 
around that
basic fact.

       Mike, done.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 19 Jul 2006 17:16:33 -0700

-1

---

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Jul 2006 19:26:48 -0700

On Jul 19, 2006, at 5:06 PM, Michael Thomas wrote:

> Wrong. DK records sign for all subdomains. That is the current  
> semantic. Changing that semantic is not backward compatible. Your  
> desire does not get around that basic fact.

Introduction of the "s" flag changes semantics in the handling of  
subdomain identities one way or the other.  Depending upon the sense,  
the flag will be introduced within the key when either there is a  
desire to constrain the signing of subdomain identities, or when  
there is a desire to not constrain them.  A change in the key record  
is needed in one case or the other.  The key record is not the only  
element affected; the DKIM signature header field version MUST also  
change.  The signature version defines the semantics of the tags.  An  
older verifier ignoring the "s" flag and the signature version gets  
the semantics wrong in either case and can not be seen as backward  
compatible.

The desired default and the recommended mode should prevail.  This is  
not an issue of retaining backward compatibility.  Imposing the  
constraint may become the norm, and the recommendation should be that  
the constraint be removed only when required.  Removal of this  
constraint is never required however.  A lack of constraint  
facilitates fabricating signing identities while eliminating the  
means to ascertain the signing domain's administrative control.  This  
mode seems highly prone to abuse.  This lack of constraint imposes  
both administrative and security concerns that may result in  
subdomain identities being commonly found unacceptable.  Just as with  
the l= tag, ignoring questionable parameters should provide correct  
behavior.  Currently the "s" flag has the wrong sense to follow this  
paradigm and defaults to an insecure mode.

While understanding the desire not to revisit the key record during  
an upgrade when signing subdomain identities, making the choice based  
upon convenience seems to provide poor results.

-Doug

---

From: Mark Delany <[email-masked]>
Date: Thu, 20 Jul 2006 03:42:43 +0000

On Wed, Jul 19, 2006 at 11:00:29PM -0400, Tony Hansen allegedly wrote:
> Paul Hoffman wrote:
> This genie's too far out of the bottle.
> 
> -1

-1. I'm with Paul and Tony.

Mark.

---

From: Tony Hansen <[email-masked]>
Date: Wed, 19 Jul 2006 23:00:29 -0400

-1