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
