[ietf-dkim] base-04 //inverting key t= 's'ub-domain flag
dotis at mail-abuse.org
Wed Jul 19 16:38:21 PDT 2006
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:
>>> 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
>> 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
> 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.
More information about the ietf-dkim