Subject: [ietf-dkim] Choices about Practice vs. Publication

From: Dave Crocker <[email-masked]>
Date: Sun, 08 Jul 2007 11:42:21 -0700

An offline discussion with Steve Atkins has been helpful in highlighting a two 
distinctions in function and implementation design that the group should 
consider.  He pressed quite hard, for some of what follows, but I won't claim 
that I'm speaking on his behalf; I just want to make sure it's clear that I 
didn't "invent" any of this:

1. Internal vs. External

     The difference between recruiting the recipient to enforce origin-side 
policies concerning origin-side participants, versus enabling the recipient to 
detect misbehaviors by actors external to the origin-side.

     I think a simple and appropriate model, here, is that the receive-side 
should be given information that permits it to detect external attacks -- that 
is, misbehaviors by actors external to the origin-side.

     The receive-side should *not* be recruited to enforce policies pertaining 
to participants within the origin-side environment.  The latter is strictly 
the job of the origin-side organization.

2. Practice vs. Publication

    Classically, this is the "what vs. how" distinction.

    What is the information that the 'sender' or signer wants to communicate 
to the receiver?  Distinct from this is the means by which it is communicated.

    The two obvious choices for communicating anything involving DKIM are:

         a) DNS publication, versus

         b) inclusion in the signed message, either as an enhancement to an 
existing header field, or as a new field.

Of course each of these has notable benefits and limitations

    DNS queries have particular performance characteristics, concerning cost, 
reliability and latency. Its major benefit is that it is an out-of-band 
channel.  Where that is essential -- such as communicating information that 
can be applied to unsigned messages -- then it is what should be used.

    However if the information is from a signer -- and it does not somehow 
require independent trust, such as obtaining it from a third-party service -- 
then it can be included in the message.

    Steve pointed out to me that a basic challenge, here, is that DKIM does 
not define a signature as meaning that the signer is asserting the 
truthfulness of any particular bit of information in the message.  That's the 
inherent difference between the mild "taking responsibility" semantics that we 
have given to a DKIM signature, versus "asserting correctness" or the like.

    My suggestion to deal with this is to define the basic DKIM sematnic that 
all DKIM-* headers are asserted to be valid, if they are included in the 
signature.

Thoughts?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Sun, 08 Jul 2007 12:21:04 -0700

Dave Crocker wrote:
> 1. Internal vs. External
>
>     The difference between recruiting the recipient to enforce 
> origin-side policies concerning origin-side participants, versus 
> enabling the recipient to detect misbehaviors by actors external to 
> the origin-side.
>
>     I think a simple and appropriate model, here, is that the 
> receive-side should be given information that permits it to detect 
> external attacks -- that is, misbehaviors by actors external to the 
> origin-side.
>
>     The receive-side should *not* be recruited to enforce policies 
> pertaining to participants within the origin-side environment.  The 
> latter is strictly the job of the origin-side organization.

In which case, the bob and jane @ earthlink problem is really earthlink's
to deal with. I think that's entirely appropriate; it is completely within
earthlink's capability to, say, use SMTP AUTH to gate users to deal with
this attack.
>    What is the information that the 'sender' or signer wants to 
> communicate to the receiver?  Distinct from this is the means by which 
> it is communicated.
>
>         b) inclusion in the signed message, either as an enhancement 
> to an existing header field, or as a new field.

There's really a third dimension too: the "unsigned" message problem.
>    DNS queries have particular performance characteristics, concerning 
> cost, reliability and latency. Its major benefit is that it is an 
> out-of-band channel.  Where that is essential -- such as communicating 
> information that can be applied to unsigned messages -- then it is 
> what should be used.
>
>    However if the information is from a signer -- and it does not 
> somehow require independent trust, such as obtaining it from a 
> third-party service -- then it can be included in the message.
>
The subdivision of labor with DKIM has pretty much been: if it's
something that constrains a key, then it goes in the DNS record.
Everything else goes in the signature header. This seems pretty
clean.
>
>    Steve pointed out to me that a basic challenge, here, is that DKIM 
> does not define a signature as meaning that the signer is asserting 
> the truthfulness of any particular bit of information in the message.  
> That's the inherent difference between the mild "taking 
> responsibility" semantics that we have given to a DKIM signature, 
> versus "asserting correctness" or the like.
>
>    My suggestion to deal with this is to define the basic DKIM 
> sematnic that all DKIM-* headers are asserted to be valid, if they are 
> included in the signature.
I'm not really sure where you're going with this, and I don't
think I like the implications. If a signer asserts something, it's
motivation for asserting it has to always be viewed with the
possibility of being gamed. So I don't know what "valid"
means through that lens. Useful information to a receiver can
only be of the "negative" variety; economists probably have
language for this, but information that there is no incentive for
the signer to lie about. Typically these are things that constrain
the degrees of freedom rather than increase them, which is
exactly what the current crop of tags in DKIM do.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Sun, 8 Jul 2007 16:37:05 -0700

On Jul 8, 2007, at 11:42 AM, Dave Crocker wrote:

> An offline discussion with Steve Atkins has been helpful in  
> highlighting a two distinctions in function and implementation  
> design that the group should consider.  He pressed quite hard, for  
> some of what follows, but I won't claim that I'm speaking on his  
> behalf; I just want to make sure it's clear that I didn't "invent"  
> any of this:
>
> 1. Internal vs. External
>

There will not be much sympathy for having bounced replay abuse, when  
the victim is also the signing domain.  Be aware that IP reputation  
schemes may not be generous to those bouncing the message.  In  
addition, there are many domains where "same-domain" replay abuse  
might become problematic.  Those forwarding messages into such a  
domain will appear fairly similar to "same-domain" replay abuse.  It  
should not be assumed "same-domain" replay abuse only occurs via a  
spoofed MailFrom addresses where BATV might prove useful.

> communicate to the receiver?  Distinct from this is the means by  
> which it is communicated.
>

DKIM is normally related to the "originating" domain, but DKIM can  
also be added by subsequent domains.  When attempting to ascertain a  
potential for replay abuse, finding the SMTP client within the  
signing domain precludes a replay abuse concern.  When an originating  
email-address domain differs from that of a subsequent signing  
domain, then ONLY WHEN the signing domain has been explicitly  
authorized by the originating domain can replay abuse be excluded.   
Without an ability to preclude possible replay abuse, acceptance will  
likely remain based upon the reputation of the SMTP client's IP address.

Transparent authorization accomplished through an exchange of keys  
defeats being able to preclude the potential for replay abuse.  Even  
when the originator and the subsequent provider both sign, explicit  
authorization is needed to permit the SMTP client to be within the  
signing domain of the originating email-address.  An explicit  
authorization via a DNS record can provide such authorization by- 
name.  The method can be very scalable and within a single  
transaction which is likely needed anyway.

Relying upon SPF/Sender-ID as a type of authorization places DNS  
itself at risk where this scheme might incur many additional  
transactions.  In addition, SPF/Sender-ID is based upon constructing  
comprehensive IP address lists.  As IPv6 use increases, IP addresses  
will become fairly dynamic as well.

When the message is unsigned, the check will be for a normal SSP RR.   
When the message is signed, a check could be for a TPA-SSP RR  
instead.  Even a subsequent transaction for the SSP RR could be  
eliminated by a wildcard below the SSP record.  Even so, wildcard  
records should be avoided.  The next transaction will likely check  
the existence of an MX or A RRs to validate the email-address  
domain.  This approach precludes transactions traversing the entire  
domain.

>         b) inclusion in the signed message, either as an  
> enhancement to an existing header field, or as a new field.

A signing domain may wish to make assurances related to the validity  
of the MailFrom address.  Such an assurance may improve the integrity  
of DSNs when the MailFrom email-address differs from that of the 'i='  
parameter.  Such a header could also assure "authorized" domains  
which might differ entirely from that of the signing domain.  Such a  
feature could also assist with "same-domain" replay abuse resulting  
from spoofed bounce addresses.  In this case, the header would not  
need to be standardized.

>    DNS queries have particular performance characteristics,  
> concerning cost, reliability and latency. Its major benefit is that  
> it is an out-of-band channel.  Where that is essential -- such as  
> communicating information that can be applied to unsigned messages  
> -- then it is what should be used.
>

This would be true except when dealing with possible replay abuse.   
When the ability to replay DKIM messages is exploited, deliverability  
of a message may depend upon being able to determine a relationship  
between the SMTP client and that of the signing domain.  Otherwise,  
the IP address used by the client remains the only safe reference to  
base reputations.

>   Steve pointed out to me that a basic challenge, here, is that  
> DKIM does not define a signature as meaning that the signer is  
> asserting the truthfulness of any particular bit of information in  
> the message.  That's the inherent difference between the mild  
> "taking responsibility" semantics that we have given to a DKIM  
> signature, versus "asserting correctness" or the like.
>
> sematnic that all DKIM-* headers are asserted to be valid, if they  
> are included in the signature.

This assertion in many cases would need to exclude the From address,  
but this header is required to be signed.  Use of the "i=' parameter  
is likely the only positive means to communicate such an assurance  
and is already defined within DKIM base.

-Doug

---

From: Steve Atkins <[email-masked]>
Date: Sun, 8 Jul 2007 16:46:38 -0700

On Jul 8, 2007, at 4:37 PM, Douglas Otis wrote:

> This assertion in many cases would need to exclude the From  
> address, but this header is required to be signed.  Use of the "i='  
> parameter is likely the only positive means to communicate such an  
> assurance and is already defined within DKIM base.

"From" does not start with "DKIM-".

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Sun, 8 Jul 2007 20:15:16 -0700

On Jul 8, 2007, at 4:46 PM, Steve Atkins wrote:

>>> asserting the truthfulness of any particular bit of information  
>>> in the message.  That's the inherent difference between the mild  
>>> sematnic that all DKIM-* headers are asserted to be valid, if  
>>> they are included in the signature.
>>
>> address, but this header is required to be signed.  Use of the  
>> "i=' parameter is likely the only positive means to communicate  
>> such an assurance and is already defined within DKIM base.
>

The From: field is intimately combined with the DKIM-Signature: field.

Per rfc4871:
---
5.4. Determine the Header Fields to Sign

  The From header field MUST be signed (that is, included in the "h="
  tag of the resulting DKIM-Signature header field).
___

Are you suggesting the intent is to sign other DKIM-Signatures and  
thereby assert they are also valid?

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Sat, 14 Jul 2007 22:23:01 -0400

>> external attacks -- that is, misbehaviors by actors external to the 
...
> earthlink's capability to, say, use SMTP AUTH to gate users to deal with

You might be referring to a different issue, but I think the i= parameter 
makes this particular issue moot.  Might have been an interesting discussion 
about 2 years ago, but not so much now.

> There's really a third dimension too: the "unsigned" message problem.

If the message is unsigned, then it is not a candidate for carrying DKIM 
information, is it?  Note that my list was about *mechanisms* for carrying 
information, not (at this point) about what might dictate the choice.

> Everything else goes in the signature header. This seems pretty

Well, you are certainly stating a very simple and clear rule.  However I don't 
recall that being discussed by the working group or there being any clear 
understanding among the group that that is the design policy.

In any event, what my interaction with Steve did was suggest a related, but 
somewhat different policy basis.  Note that an SSP record in the DNS, to cover 
unsigned messages, does not fit your policy rule.

> possibility of being gamed. So I don't know what "valid"

Concern for being gamed is certainly required.

> exactly what the current crop of tags in DKIM do.

"Useful information to a receiver can only be of the "negative" variety" 
strikes me as a pretty remarkable assertion, given that DKIM is far more about 
establishing positive trust than negative.

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Jul 2007 11:56:06 -0700

On Jul 14, 2007, at 7:23 PM, Dave Crocker wrote:
>>> receive-side should be given information that permits it to  
>>> detect external attacks -- that is, misbehaviors by actors  
>>> external to the origin-side.
> ...
>> In which case, the bob and jane @ earthlink problem is really  
>> earthlink's to deal with. I think that's entirely appropriate; it  
>> is completely within earthlink's capability to, say, use SMTP AUTH  
>> to gate users to deal with this attack.
>
> You might be referring to a different issue, but I think the i=  
> parameter makes this particular issue moot.  Might have been an  
> interesting discussion about 2 years ago, but not so much now.

The i= provides an identity which may omit the local-part of the  
address on who's behalf the message is signed.  DKIM does not ensure  
this identity is meaningful in regard to the visual content of a  
message.   A key located within an email-address sub-domain  
represents a third-party signature.  In which case, the i= parameter  
is unable to identify an address within a parent domain that is  
likely recognized by the recipient.   However, the overview draft  
makes an assumption regarding the utility of sub-domain signatures.   
In doing so, this creates a new security concern.  What utility was  
envisioned by this suggestion?

In the draft-ietf-dkim-overview document,
---
1.3.3.  The Selector construct
...
  Signers do have the need for supporting multiple assessments about
  their organization, such as to distinguish one type of message from
  another, or one portion of the organization from another.  To permit
  assessments that are independent, an organization should use
  different sub-domains in the "d=" parameter, such as
  "transaction.example.com" versus "newsletter.example.com", or
  productA.example.com versus productB.example.com.

2.6.1.3.  Subdomain Considerations

  A Domain Name is the basis for making differential quality
  assessments about a DKIM-signed message.  It is reasonable for a
  single organization to have a variety of very different activities,
  which warrant a variety of very different assessments.  A convenient
  way to distinguish among such activities is to sign with different
  domain names.  That is, the organization should sign with sub-domain
  names that are used for different organizational activities.
---

RFC4871:

3.5.  The DKIM-Signature Header Field
...
d=  The domain of the signing entity (plain-text; REQUIRED).  This is
     the domain that will be queried for the public key.  This domain
     MUST be the same as or a parent domain of the "i=" tag (the
     signing identity, as described below), or it MUST meet the
     requirements for parent domain signing described in Section 3.8.
     When presented with a signature that does not meet these
     requirement, verifiers MUST consider the signature invalid.
---

Note: Section 3.8 conditionally permits valid signatures for sub- 
domain email-addresses only when not disabled by a flag within key  
records.

The DKIM overview makes a recommendation that did not receive much  
list discussion.  This appears to be based upon an assumption that  
sub-domain signatures could be considered authoritative for a parent  
domain within the realm of "assessments."  "Assessments" is a rather  
nebulous term.   Even parent domain signatures represent a risk  
partially addresses by RFC4871 #3.8.  Nothing within DKIM provides a  
means to limit sub-domain signature "assessments", as such signatures  
simply are not valid for parent domain email-addresses!

Allowing parent domain signatures is problematic from a security and  
complexity standpoint.  Suggesting that sub-domains can be used for  
"assessment" purposes invites a fair amount of abuse.   This means  
the 'i=' identity is unlikely to be meaningful to the email recipient  
as well.

Was sub-domain signatures considered to be a method to partition  
domains into differently vetted categories?  Was this to isolate  
sources where replay abuse may be less problematic?  There are  
security issues created by controlling message "assessments" by sub- 
domains.   This type of signature is not itemized within the SSP  
policy, nor can these types of signatures be explicitly controlled  
beyond outright prohibition of third-party signatures.  Prohibition  
of third-party signatures thereby prevents this utility.  Is this  
recommendation based upon there being an exception in the definition  
of "third-party" signatures?

A recipient can safely obtain assurances from a sub-domain signature  
by providing a by-name SSP authorization strategy.  A by-name  
authorization as provided in TPA-SSP can thereby limit the scope of  
third-party signatures.  The difference is rather stark, specifically  
when, as the overview suggests, there is a need for multiple  
assessments.

http://www.sonic.net/~dougotis/dkim/draft-otis-dkim-tpa-ssp-01.html
http://www.ietf.org/internet-drafts/draft-otis-dkim-tpa-ssp-01.txt

-Doug