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

[Douglas Otis]

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

> Douglas Otis wrote:
>
>>
>> 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.
>
> 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