Doug,
The intention here is not to validate each point of the positive and
negative
commentary, but to bring the issues to the fore so that the entire scenario
and requirements it generates can be understood in the context of what
has gone on with the list. If I have transcribed the negative commentary
incorrectly, I'm open to fixing that, but striking each point fundamentally
misses the point of why it's in the draft.
Mike
Douglas Otis wrote:
5.3.1. Negative Commentary
Strike:
,---
|1. Scaling Concerns for DNS: the addition of third party
| signers begs the question of how that information is stored
| in the DNS if that is the repository (which seems pretty
| likely). The naive approach of just encoding them into one
| resource record could quite plausiblely exceed the maximum
| DNS UDP MTU which would be highly undesirable. Other
| approaches have been suggested, but they seemingly trade off
| complexity, number of lookups, non-deterministic completion,
| etc.
'---
Policy for a particular email-address domain can combine relevant
signing domain as a component of the DNS query. As such, only a
single query would be needed to resolve any email-address and signing
domain association. For example the query could be constructed as
follows:
s-dom-a = hash1(signing domain);
s-dom-b = hash2(signing domain);
s-dom-label = base32(s-dom-a + s-dom-b);
The policy query name for the 2822.From email-address domain would be:
<s-domain-label>._dkim_f.<from domain>
The response could be:
+-----+--------------------------------+
| Tag | Function |
+-----+--------------------------------+
| v= | Version |
| | |
| f= | Flags |
| | |
| a= | Designated Signing for Address |
| | |
| d= | Designated Signing for Domain |
| | |
+-----+--------------------------------+
+------+----------------------------------+
| Flag | Function |
+------+----------------------------------+
| A | All initial messages signed |
| | |
| N | Not signing |
| | |
| O | Only compliant services employed |
+------+----------------------------------+
Note: The difference between the 'a=' and the 'd=' tags provides a
means to indicate whether the email-addresses should be considered
validated in lieu of the normal 'i=' syntax.
This query can be synthesized as follows:
*._dkim_f.<from domain> RR "a=from domain; f=A:O;
hash-o-signer._dkim_f.<from domain> RR "a=signing domain; f=A:O;
This list can be extended as need and still need only a single
transaction.
Strike:
,---
|2. Alternate mechanism to NS delegation, and threats not well
| understood: the mechanism for delegating zones within DNS is
| a very well understood problem which well understood
| threats. The threats involved with another form of
| indirection are far less clear, though undoubtably present.
| There is a great deal of concern that (re)discovering those
| threats, deciding whether they are valid, whether they need
| to mitigated, etc, etc are a worthwhile exercise given that
| this provides minimal functionality over what currently
| exists with DKIM base.
'---
The threat related to DNS delegation is not well considered with
respect to DKIM. The characterization of a designation scheme
offering only minimal functionality over that of DNS delegation or
key exchanges fully underestimates the scale and the administrative
obstacles limiting the use of DKIM as a means to prevent spoofing at
all levels.
One such threat not well considered is abuse reporting protecting the
transmitting system whose reputation is determined by their IP
address. The IP address should be associated with that of the
signing domain, or the transmitting system is less secure from the
affects of abuse, or the utility afford by DKIM for abuse reporting
will have been seriously hampered. Stopping abuse is where the
threats are prevented. DNS delegation actually impedes this critical
effort!
Strike:
,---
|4. Concerns about conflation of responsibility and/or
| reputation: there are concerns of adding to the confusion
| about who is taking responsibility for what. Is it the d=
| domain in the DKIM-signature? Is it the domain in the From:
| address? Is it both? Is it neither? Keeping this simple
| by using the NS delegation mechanism would not raise these
| interesting, if not thorny questions.
'---
Only verified identities can accrue behavioral histories and be held
accountable. While the signing domain might offer assurances an
email-address contained within a message is valid, this assurance can
not be directly verified. It is illogical to consider an abusive
message to be from a bad actor, and then trust this bad actor's
assurances with respect to an email-address domain. Only directly
verified identities allow negative information to be accrued. An
email-address is not such an identity unless S/MIME or OpenPGP is
considered.
Strike:
,---
|5. It's not clear that this requirement actually delivers on
| the less complexity aspect of its billing: one of the
| attractions of this requirement is that there would be
| little or no interaction required between the first party
| and the designated third party signer. Given the security
| issues with this approach, it is not clear that the
| interaction required between the first and third parties are
| any less onerous.
'---
This is clearly a one-sided view lacking any basis. Either
designation or delegation depends upon the actions of the provider.
In the case of the designated domain scheme, only validated email-
addresses are signed by a "clean" domain. The designation policy can
also convey whether the email-address should be considered valid as
illustrated in the above example. There is no mechanism for this to
be done via delegation. There are also several security issues
ignored in this statement from the aspect of refuting a message,
abuse reporting, and the risks that might be associated with domain
delegation or key exchanges.
Strike:
,---
|6. Security Threat with DKIM base, a first party signer can
| always clarify which address it is signing on behalf of by
| using the i= tag. That is, when there's ambiguity between,
| say, From: and Sender: the signer has the ability to clarify
| which address the signature was on behalf of if it so
| desires. For a third party signature, there is no clarity
| since the signature by definition has no relationship to the
| origination addresses.
|
| A legitimate flow follows:
|
| - An ISP signs for both a.com and mailinglist.com
|
| - mailinglist.com sends a piece of mail From:
| president(_at_)a(_dot_)com, Sender: list(_at_)mailinglist(_dot_)com
|
| - ISP signs the message with d=ISP.com
|
| - The receiver at this point has no idea who ISP.com was
| signing on behalf of because they are both
| legitimately signed by ISP.com
|
| The attack is essentially identical: it only requires that
| mailinglist.com spoof the From: address to whatever other
| customer of ISP.com. That is, mailinglist.com can be any
| example.com with bad intentions. Worse, is that the ISP
| will ordinarily have no clue as to whether its customers are
| running mailing lists or not, so it would not have the
| ability "legitimate" From: spoofing (ie, a real mailing
| list) from illegitimate spoofing.
'---
This poses an illogical scenario where trust is misplaced. Anyone
that decides to designate a signing domain must be assured by the
provider the domain they designate as providing valid email-addresses
is kept "clean". A "clean" domain would be one where only validated
email-addresses are signed.
The process of validating an email-address is common place and done
by thousands of applications from mailing-list mangers, the
assignment of email-certificates, or granting access to web-sites.
In either a designated or delegated schemes, accounts granting access
must restrict the email-address being used, or DKIM semantics must
not indicate assurances that the email-address is valid.
The example of a designated policy illustrates how the 'i=' syntax is
replaced. In fact, a delegation process may not be able to properly
differentiate which email-address should be included within the 'i='
parameter. With the designation scheme, when the signing domain is
listed in the 'd=' tag, the email-address should not be considered
valid. When listed in the 'a=' tag, then the email-address that
references the policy and matches the signing domain can be assumed
to be valid.
As always, the signing domain must be trustworthy, but unlike when
delegation is used, who is being trusted remains apparent and reports
of abuse are properly directed. Designation represents improved
security.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html