Eliot Lear wrote:
Please don't expect to see new issues opened until after the 2nd.
Before the holiday spirits do further damage to my brain cells, I
thought I should gather my thoughts on this together now and during the
interim, post this as a new issue now for preliminary list discussion
and consideration. Then maybe after the 2nd, it may or may not be an
issue to open.
New Issue: Do we need SSP record for DKIM=unknown?
Summary:
Since the NO SSP record world message handling semantics is consistent
with a DKIM-BASE only world, it would be waste of DNS resources for
verifiers to do SSP lookups and the records translate to default
DKIM-BASE semantics.
The incentive for implementing SSP records is to provide a payoff for
all parties; a) the DKIM signer whose values security over delivery and
b) the DKIM verifier whose desire is to provide a higher payoff
(compared to no payoff) service that will benefit the DKIM domain, the
receiver system and its users.
In addition, by removing the relaxed default SSP attributes, it will
help in reducing exploitations and fraud. SSP should only be used to
help strengthen the domain DKIM signing process, not add any new
complexity or confusion over what the domains intentions are.
Background:
This might appear complex to explain because I do complicate it with
sub-issues which may be considered separately. So before someone suggest
that these sub-issues may be multiple separate issues, please look at
this first as a whole. My goal here is to help make SSP worthy for
adoption consideration by reducing any perceived complexity about it.
Currently, SSP-01 has the following record syntax information:
dkim = unknown|strict|all default: unknown
handling = process|deny default: process
t = y|s default: undefined
So the default DKIM-BASE behavior from a SSP point of view is:
dkim=unknown handling=process
and this includes the idea when there is no SSP record.
Overall, we want protocol consistency in DKIM/SSP, therefore:
- if a verifier has SSP support and performs a domain
SSP lookup and no record is found, the above is the default
SSP attributes.
- Likewise, if a verifier is ignorant of SSP (early
versions of DKIM-BASE only verifiers), the SSP specification
should be modeled on the idea that non-SSP verifiers will
behave with the default SSP like attributes.
I do believe we achieve this goal here. However, I also believe it is
redundant, can be exploited and lowers the incentive for using SSP.
To explain why, lets look at some additional sub-issues:
sub-issue: t default not "spelled out"
I think SSP-01 should be explicit in saying no t= tag means
the system is not testing and that all sub-domains are in play.
This is a minor sub-issue especially since we are also considering
removing the t=y 'testing' semantics.
sub-issue: handling=process default is ambiguous.
The text for handling=process says:
process Messages which are Suspicious from this domain SHOULD
be processed by the verifier, although the SSP
failure MAY be considered in subsequent evaluation of
the message. This is the default value.
Since handling=process is the default, this is where the key new issue
for the necessity of a SSP record for DKIM=unknown comes into play.
Lets assume there is no SSP record as it realistically might be in the
current and early DKIM-BASE RFC 4871 adoption period.
In this DKIM-BASE only world, the specification already makes it clear
that a DKIM-BASE message should be further evaluated using additional
message processing layer(s).
So in this vain, the default SSP record is redundant. The only time a
SSP record is provides added value or payoff is when the domain wants a
different signing verification logic than what is otherwise provided
with the DKIM-BASE semantics.
Therefore, one might suggest the only necessary options for SSP might be
just:
dkim = strict|all default: all
t = s default: sub-domains allowed
Since we already have a SSP issue on the table to remove the t=y testing
option with a high consensus to remove it, this reduces the tag to a t=s
only option.
Since the default DKIM-BASE semantics is to further evaluate messages,
valid or invalid, the handling=process is redundant and offers nothing
new to the model.
Conclusion:
Since the NO SSP record world message handling semantics is consistent
with a DKIM-BASE only world, it would be waste of DNS resources for
verifiers to do SSP lookups and the records translate to default
DKIM-BASE semantics.
The incentive for implementing SSP records is to provide a payoff for
all parties; a) the DKIM signer whose values security over delivery and
b) the DKIM verifier whose desire is to provide a higher payoff
(compared to no payoff) service that will benefit the DKIM domain, the
receiver system and its users.
In addition, by removing the relaxed default SSP attributes, it will
help in reducing exploitations and fraud. SSP should only be used to
help strengthen the domain DKIM signing process, not add any new
complexity or confusion over what the domains intentions are.
--
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