Subject: [ietf-dkim] New Issue: ssp-requirements-01 // Negative Commentary corrections

From: Douglas Otis <[email-masked]>
Date: Wed, 20 Sep 2006 19:05:24 -0700

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:
|       [email-masked], Sender: [email-masked]
|
|    -  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

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 21 Sep 2006 09:04:00 +0200

Douglas Otis wrote:

> 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.

NAK, that's far from common, from four mail providers I used
to know only one enforced submission rights (=> good reverse
path, arbitrary header), and another - putting it mildly -
implemented his own vision of 4409 8.1 (=> good reverse path
with enforced matching 2822-From), offering the more common
"whatever you say" for a small monthly fee (maybe to sponsor
their abuse desk).

The third doesn't care what I say after I'm authenticated with
LOGIN (in the clear, their TLS is optional), and the fourth
also doesn't care (pure RADIUS), but runs now a spam check on
outbound mail.

BTW, I'm looking for interested folks helping to fix RFC 4409
8.1, and then push a derived 4409bis to STD (see rfc822 list).

Frank

---

From: Douglas Otis <[email-masked]>
Date: Thu, 21 Sep 2006 11:02:20 -0700

On Sep 21, 2006, at 12:04 AM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
>> The process of validating an email-address is common place and  
>> done by thousands of applications from mailing-list mangers, the  
> NAK, that's far from common, from four mail providers I used to  
> know only one enforced submission rights (=> good reverse path,  
> arbitrary header), and another - putting it mildly - implemented  
> his own vision of 4409 8.1 (=> good reverse path with enforced  
> matching 2822-From), offering the more common "whatever you say"  
> for a small monthly fee (maybe to sponsor their abuse desk).

For any version of DKIM to realistically offer assurances of an email- 
address, some form of account/email-address correspondence is  
required.  The version of the email-address policy suggested does not  
required the assertion that the email-address is valid.  However, an  
ability to communicate when an email-address is valid, and have this  
presented by a well-known and trusted domain will bring considerable  
value to DKIM as a specialized service.

> BTW, I'm looking for interested folks helping to fix RFC 4409 8.1,  
> and then push a derived 4409bis to STD (see rfc822 list).

I'll review that document and subscribe to the rfc822 list.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Fri, 22 Sep 2006 13:56:26 -0700

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 22 Sep 2006 15:53:29 -0700

On Sep 22, 2006, at 1:56 PM, Michael Thomas wrote:

> 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.

This transcribed commentary is one-sided and lacking a basis.   
Whether supported by a few on list at the time, it is still wrong and  
does not belong in  the requirements document.

Being able to associate signing domains with various email-addresses  
without involving three different organizations is critical for  
allowing DKIM to scale and to offer a greater scope of protection.   
Don't suggest delegating one's domain or allowing third parties  
access to private keys is without even more significant risks.

The basis of the these negative concerns presume:

  A-  the designated signing domain is unable to restrict
      access against non-validated email-addresses. (How is
      the 'i=' syntax be expected to work?)

  B-  the policy for the designated domain is unable to assert
      that an email-address should not be presumed valid.

  C-  the policy can not scale as needed or is complex.

  D-  a designated domain may confuse who should be held
      accountable. (Hint: whoever signed or IP address)

  E-  the signing domain should only associate with the
      From email-address, not the domain administrating the
      client whose IP address _will_ be held accountable. : O

  E-  only the email-address domain owner benefits from DKIM
      abuse reporting.

  F-  sharing a private keys or domain with a third-party
      is well understood and therefore safe.

  G-  referencing a signing domain within a policy is
      fraught with security risks avoided by sharing keys
      and domains.

DKIM will not fulfill any provider's dream that they no longer need  
to worry about what comes out of their networks.  DKIM will provide  
them clean and noise-free feedback.  For this feedback, _they_ must  
be the one's signing with _their_ keys and not that of their  
customers. : O

When the provider insists upon using their keys is where policy plays  
a vital and valuable role.  The policy for an email-address, whether  
it is the 2822.From or the 2821.MAIL_FROM, can associate a provider's  
signing domain without the provider needing to coordinate several  
complex details with the customer and the customer's DNS provider.   
Scaling.

The reason for even obtaining a policy records is to determine  
whether the email-address is associated with the signing domain.  By  
allowing comprehensive coverage of a single signing domain, this  
policy can allow annotations of retained email-addresses that protect  
Eliot's dad.  Others may expect that policy only blocks exact-domain  
spoofing, but this is likely only wishful thinking.  Don't be too  
sure that blocking some very small percentage of abuse justifies  
searching up label trees after each and every message received.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Fri, 22 Sep 2006 16:12:28 -0700

Douglas Otis wrote:

>> 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.
>
>

It's not one sided -- it's my attempt to summarize what a lot of voices 
on the
list have said. As for lacking a basis or "wrong", that's true if the 
only one who
gets a say as to what constitutes "basis" or "right" is you. Aside from 
being unfair,
it's not the point of the draft either: the draft's intent is to 
summarize what people
want, what people don't want, and whether the wants are feasible or 
needed now
so that we can have a basis to decide what the subset of wants 
(requirements) that
we will  demand of the protocol.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Tue, 26 Sep 2006 10:25:58 -0700

On Sep 22, 2006, at 4:12 PM, Michael Thomas wrote:
>>> 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.
>>
>> Whether supported by a few on list at the time, it is still wrong  
>> and  does not belong in  the requirements document.
>
> It's not one sided -- it's my attempt to summarize what a lot of  
> voices on the list have said. As for lacking a basis or "wrong",  
> that's true if the only one who gets a say as to what constitutes  
> "basis" or "right" is you. Aside from being unfair, it's not the  
> point of the draft either: the draft's intent is to summarize what  
> people want, what people don't want, and whether the wants are  
> feasible or needed now so that we can have a basis to decide what  
> the subset of wants (requirements) that we will  demand of the  
> protocol.

It is clear from other comments on the list, you oppose a concept of  
designation rather than delegation.  The basis for the negative  
commentary presumes DNS delegation is less risky or represents  
current practices.  Several on this list, including Stephen,  
expressed concerns regarding DNS delegation with the exchange or  
possession of private keys by third-parties.  This continues to be  
ignored in this requirements draft.  DKIM's use of selectors, private  
keys, key specific settings, etcetera, represent significant and new  
complexities with a DNS delegation technique.  I see no purpose in  
adding the negative commentary other than to introduce impediments to  
fuller discussions or to summarily dismiss the designation technique  
altogether.

In either situation of designation or delegation, the provider must  
be trustworthy.  As possible with the 'i=' semantics in the signature  
header denoting when the email-address has not been validated, the  
same semantics are equally possible with any reasonable designation  
technique, but where the email-address domain owner controls the  
assertion.  When the goal is to ensure a message is signed by a  
designated entity for acceptance, assurances of email-address  
validity may be secondary.  In the current email infrastructure,  
assurances of an email-address being valid may be the exception.   
Even so, a designation technique still allows validation techniques  
that are confirmed with a designation assertion.

Does anyone think that:

<base32(sha(signing-domain))>._dkim-hdr-x.<email-domain> TXT  
"d=signing-domain; f=A;"

This represents a single DNS lookup of a small RR.  Does any think  
this is overly complex and does not scale?

While clearly some may find nirvana having all originating domains  
match the signing domain, this is not practical.

There is value in having the signing-domain be concurrent with that  
of the domain administrating the actual transmission of the message.   
Here DKIM would ensure abuse feedback finds the appropriate party.

A simple technique to associate the signing domain with other email- 
addresses within the message allows DKIM to block forged DSNs for  
example.  It would also allow the email-address domain owner to  
autonomously decide whether they wish to designate their provider,  
and to indicate specifically what role the provider plays.  DNS  
delegation removes control from the email-address domain owner, while  
at the same time requires the email-address domain owner to answer  
for signed content they may have never seen!

The negative commentary does not belong in the requirements draft.   
It is wrong and biased.

-Doug