Hector Santos wrote:
Jim Fenton wrote:
Hector,
Publishing an SSP record with the default values results in better
caching, because a positive result typically has a longer TTL than a
negative result, whose TTL which is the minimum TTL of the zone. With
the current lookup algorithm, it also relieves the verifier of the
need to confirm the domain's existence, since without an SSP
record the result of the query will frequently be an NXDOMAIN.
-Jim
Thanks Jim.
Please correct me if I wrong, it would then be "Recommended" for DKIM
domains to consider using a SSP record even if the domain intent is to
operate in DKIM-BASE mode? So even if the DOMAIN has no intention to
use the benefits of SSP beyond its default behavior, it SHOULD create
a SSP record in order to be DNS friendly and cooperative with
verifiers with SSP support? Is this idea stated or implied in the
SSP-01 specs?
I don't think it says that in SSP-01. My own view is that this is more
of a deployment issue, and more properly belongs in the overview or
deployment document than in the SSP specification itself.
On a related note, I didn't want to bring this up before but I think
it might be something of interest.
With the goals of reducing redundancy, complexing and improving SSP
adoptability, would it be feasible to consider for SSP restrictive
policies only that a DKIM domain MAY expose its policy via the
DKIM-BASE key record?
IOW, if a high value domain's only desire or interest in SSP is to
expose restrictive handling, would it make sense to write a RFC 4871
"add-on" or "Extension" I-D or using the opportunity now to write
directly into the SSP specification the proposal of a new DKIM tag
that exposes strict or all domain DKIM transaction information?
[details omitted]
The cases where this might be beneficial are when there is an invalid
Author signature or when there's another signature, valid or invalid, in
the Author's domain, in all cases referencing a valid selector. The
invalid Author signature case will probably be relatively common, but
signatures from other addresses in the domain less so. It does seem
that this might reduce the number of SSP lookups a bit, however it would
be necessary for a domain using this extension to ensure that the SSP
information in all key records is consistent with that of the domain's
SSP record.
One potential threat occurs if a domain decides to CNAME any of its key
records to an external party. That party would now have the ability to
publish a key record with a different (probably looser) SSP than that of
the domain's SSP record. This shouldn't be much of a concern since the
party controlling the record can sign for the author domain anyway, but
if this is done accidentally it would leave an opening for attackers to
take advantage of the situation by adding invalid signatures referencing
the key record with the looser SSP.
The SSP extension to key records would never be sufficient; stand-alone
SSP records would need to be published as well. I'd like to suggest
that we concentrate on the "basic" SSP concept for now and keep
optimizations such as this for discussion later.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html