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?
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?
The idea is this:
Optional extended DKIM key tag: SSP=strict|all
For example, following SSP-01
1. If a valid Originator Signature exists, the message is not
Suspicious, and the algorithm terminates.
This means that the signature was verified via DKIM-BASE. It also means
the DKIM key record was obtained and all information points to a 1st
party signature.
As I recall during the TA review process, I believe we all agreed that
in lieu of an internal key theft, there would be no realistic external
protocol model threat here with a 1st party valid signature. So it was
safe to conclude that a SSP lookup would not be required for a valid 1st
party signature.
Continuing beyond step 1 implies we the following states:
a) valid 3rd party signature,
b) no signature (which can be from a broken signature)
So step 2 and 3 deals with the SSP discovery process.
My proposal is this:
We can reduce step 2 and 3 or short circuits the steps if the DKIM key
record obtained in step 1 contained the SSP policy information.
So in step 1, we can add a sub-steps:
1a) If we have a valid 3rd party signature or no signature, and
the key record contains a tag SSP=strict, then the message
is Suspicious and the algorithm terminates.
1b) If we have no signature, and the key record contains
a tag SSP=ALL, then the message is Suspicious
and the algorithm terminates.
The whole point is that under strict DKIM/SSP operations there is only
one party involved and no other party or unsigned messages are expected
and under the ALL policy, there is only 1 state the message can be in -
a signed state.
In both cases, we short circuit the need to do a SSP discovery by adding
an optional DKIM-BASE SSP= tag option to DKIM-BASE key records. I
believe RFC are allowed to update other RFCs, and this would be a good
opportunity to close some complex interface issues regarding DKIM-BASE
and SSP.
If no SSP= tag is found, then the verifier would proceed with the
current recommended steps.
A point to consider is that the proposal deals a Negative Classification
only, hence bad guys will not have any incentive to exploit.
Off hand, I don't see a threat here. So if you see a flaw here, please
show me the light :-)
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html