Subject: Re: [ietf-dkim] dkim-ssp-req-00// Designated Domain + DKIM SignerExtended

From: "Hector Santos" <[email-masked]>
Date: Mon, 14 Aug 2006 05:16:51 -0400

From: "Douglas Otis"

> A complete diffs of all edits are at:
> http://www.sonic.net/~dougotis/dkim/dkim-ssp-req-diff.html

Did I miss something? Where is this second draft where the diff is being
done on?    The first one had 10 section 5.3 requirements.  This other "one"
seems to have 13?

This is what I have:

http://www.ietf.org/internet-drafts/draft-ietf-dkim-ssp-requirements-00.txt

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 14 Aug 2006 02:57:59 -0700

On Aug 14, 2006, at 2:16 AM, Hector Santos wrote:

> Did I miss something? Where is this second draft where the diff is  
> being done on?    The first one had 10 section 5.3 requirements.   
> This other "one" seems to have 13?

This diff represents the difference between the existing 00 draft and  
edits that are being suggested.  You did not miss seeing any draft.   
The initial attempt to add these changes piecemeal was rejected.   
There was a lack of understanding for the significance of each  
separately.  This approach was taken in the hopes of providing a  
coherent set of suggestions.  If this can be understood in total,  
then perhaps taking the changes piecemeal might be attempted once again.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Mon, 14 Aug 2006 01:54:24 -0700

The diff also includes a few corrections for typos, and incorporates a
a completed reference.

2.  Definitions

Adds:
    o  Designated Domain: A domain that is authoritative for the First
       Party Address.  A First Party Address can be considered validated
       when signed by a Designated Domain.

Modifies:
    o  DKIM Signer Complete: The state where the domain holder believes
       that all legitimate mail purportedly from the domain are sent  
with
       a valid DKIM signature.  This state indicates only compliant
       services are used.

Adds:
    o  DKIM Signer Extended: The DKIM Signer Complete state applies, but
       with a proviso that common and possibly non-compliant services  
are
       also used.

Modifies:
3.  Introduction

    The DomainKeys Identified Mail working group is chartered to  
create a
    base signing mechanism for email.  This work is contained in
    [I-D.ietf-dkim-base].  In addition there are two other documents
    [I-D.ietf-dkim-overview] and [I-D.ietf-dkim-threats] which give an
    overview and a threat analysis of the chartered work.  This draft
    reflects the requirements for the last part of the chartered work to
    define a protocol for published DKIM signing practices.

    While the base signing document defines a mechanism for signing and
    verifying DKIM signatures, there has been a great deal of  
interest in
    a signing practices protocol.  The most pressing case seems to be  
the
    bid down attack inherent with almost all systems that allow optional
    authentication: how does a receiver know whether or not it should
    expect a message to contain authentication information?  For email
    this is an especially difficult problem since generally there is  
no a
    priori knowledge of other domains, so the safe assumption is the
    lowest common denominator which is no authentication at all.  Thus a
    protocol needs to be developed which can allow a DKIM message
    verifier to determine a DKIM posture for the [RFC2822].From address
    domain in the messages it receives.

    The [RFC2822].From address represents the apparent originator or
    author of the message.  A policy protocol referenced from this  
domain
    will not offer resilient protection and may disrupt common email
    services, especially when protection depends upon exclusion of non-
    compliant messages.  As stated in [I-D.ietf-dkim-threats],  
techniques
    affecting the visual appearance of this address creates a high  
impact
    exploit with a high likelihood of success.  However, message
    annotation based upon the recognition of the [RFC2822].From address
    found within an address book or correspondence log offers the
    requisite a priori knowledge.  For annotation to be safely applied
    however, the address must be validated by an authoritative signing
    domain.  Here policy offers significant value by both indicating and
    facilitating the association of multiple authoritative signing
    domains.

    Delegating domains or exchanging key/selector information involves
    the coordination of three entities making this means of association
    difficult to scale.  This barrier inhibits the autonomous
    administration of authoritative relationships.  To help overcome  
this
    administrative barrier, policy can offer a list of authoritative

    signing domains for the [RFC2822].From address domain.  In addition,
    until MUA based annotation is more common, policy can also assert  
all
    messages are always signed by an authoritative domain.  Asserting a
    policy without exceptions for the [RFC2822].From address is likely
    only suitable for a fairly limited number of domains.  It is fairly
    common for users to have their messages carried by other services
    like a mailing list, where a policy exception would then be needed.

Modifies:
4.1.  Scenario 1: Bigbank.example.com using DKIM Signer Complete

    There seems to be a class of mail -- mostly transactional mail from
    high value domains -- that are the target of phishing attacks.  In
    particular, the phishing scams forge the [RFC2822].From address in
    addition to spoofing much of the content to trick unsuspecting users
    into revealing sensitive information.  Domain holders sending this
    kind of mail would like the ability to guarantee that their mail is
    always from them.  The first step is, of course, to use DKIM-base to
    sign all of their outgoing mail so that a receiver can make a
    positive determination that the mail is from the domain holder in
    question.

    The problem with this scenario is that a receiver in the general  
case
    doesn't know what the practices are for a given domain, or what  
their
    expectations are for unsigned mail.  An information service, which
    allowed a receiver to query for those practices, could be useful to
    close the gap where an attacker merely sends unsigned mail to  
exploit
    a bid down attack.  It is assumed that receivers would use this
    information to treat such questionable mail with extreme prejudice
    when no policy exceptions are made.

    Note that for the foreseeable future, DKIM signature breakage for
    unrestricted use patterns (ie with users and especially where users
    are members of mailing lists) will likely suffer occasional  
damage in
    transit.  While probably not a large percentage of total traffic,  
the
    kind (quality) of breakage may be significant for certain usage
    patterns.  As such, this scenario defines a more limited situation
    where the risk of a legitimate piece of mail being mislabeled as
    unsigned outweighs the risk of illegitimate mail being delivered in
    the eyes of the sender.

    1.  A purportedly sends to B with a missing or broken DKIM signature
        from A.

    2.  B would like to know whether that is an acceptable state of
        affairs.

4.2.  Scenario 2: DKIM Signer Extended

    After auditing their outgoing mail and deploying DKIM signing for  
all
    of their legitimate outgoing mail, a domain could be said to be DKIM
    Signer Extended when common services are also used.  That is, the
    domain has to the best of its ability insured that all mail from  
that
    domain contains a valid DKIM signature, but that some common  
services
    are also used that may not be compliant.  Given the likelihood of
    signature damage in the current mail infrastructure as noted  
above, a
    domain can fit the DKIM Signer Extended scenario without wanting to
    take the risks associated with the more narrow scope of use in the
    previous scenario of DKIM Signer Complete.  A receiver, on the other
    hand, may still be able to take advantage of the knowledge the
    domain's practice of signing all mail when evaluating sources of  
non-
    complaint messages.

4.3.  Scenario 3: First Party Address Validation with Designated Domains

    Many domains do not run their own mail infrastructure, or may
    outsource parts of it to third parties.  It is desirable for a  
domain
    holder to have the ability to enumerate a list of Designated Domains
    that are authoritative for the First Party Address.  A signing  
domain
    outside the First Party Address domain is unable to stipulate with
    the 'i=' syntax an address validation operation.  Any listed
    Designated Domain, including the domain of the First Party Address,
    must be assumed to have validated the use the First Party  
Address.  A
    Designated Domain list therefore offers a stronger assertion than
    just a First Party Signature regarding the valid use of a First  
Party
    Address.  One obvious use scenario is a domain holder for a small
    domain that needs to have an ability for their outgoing ISP to sign
    all of their mail on their behalf.  Other use scenarios include
    outsourced bulk mail for marketing campaigns, as well as outsourcing
    various business functions such as insurance benefits, etc.

    That said, DKIM uses DNS to store selectors.  Thus there is always
    the ability for a domain holder to delegate all or parts of the
    _domainkey subdomain to a third party of the domain holder's
    choosing.  That is, the domain holder can always set a NS record for
    _domainkey.example.com to, say, an email provider who manages that
    namespace.  There is also the ability for the domain holder to
    partition its namespace into subdomains as a means to further
    constrain delegated third parties.  For example, a domain holder
    could delegate tp-1._domainkey.benefits.example.com to a third  
party.
    This delegation limits this third party to being able to create  
First
    Party Signatures for messages on behalf of just the benefits
    subdomain.

    There have been concerns expressed about how well this would scale
    when the third party is, say, a large ISP that signs for  
thousands of
    domains.  There has been concern about how well this would work for
    multiple delegations.  Lastly, using NS delegations requires that  
the
    signer actively cooperate with the domain for whom it is signing.
    That is, it requires that the signer actively manage the _domainkey
    delegation for the domain holder.  Without the use of a Designated
    Domain list, a domain holder would not, for example, be able to make
    a statement that ISP.com signing on its behalf is acceptable without
    ISP.com's cooperation.  Depending upon the practices of a common
    service such as a mailing list, a domain holder might wish to  
include
    the service within the Designated Domain list as an alternative to
    domain delegation.  This method could prove useful when DKIM Signer
    Complete policy is being asserted.

Modifies:
5.3.  Practice and Expectation Requirements

    In this section, a Practice is defined as a true statement according
    to the [RFC2822].From address domain holder of its intended
    externally viewable behavior.  An Expectation combines with a
    Practice to convey what this domain holder considers the likely
    outcome of the survivability of the Practice at a receiver.  For
    example, a Practice that X is true when it leaves the domain, and an
    Expectation that it will|will-not|may|may-not remain true for some/
    all receivers.

    1.   The Protocol MUST be able to make Practices and Expectation
         assertions about the [RFC2822].From address in the context of
         DKIM.  The Protocol will not make assertions about other
         addresses for DKIM at this time.

    2.   The Protocol MUST be able to publish a Practice that the domain
         doesn't send mail.

    3.   The Protocol MUST be able to publish a Practice that the
         domain's signing behavior is "DKIM Signer Complete."

    4.   The Protocol MUST be able to publish a Practice that the
         domain's signing behavior is "DKIM Signer Extended."

    5.   The Protocol MUST be able to publish a Practice that the
         domain's signing behavior is neither "DKIM Signer Complete" or
         "DKIM Signer Extended."

    6.   The Protocol MUST be able to publish an Expectation that a
         verifiable Designated Domain Signature should be expected on
         receipt of a message.

         [Informative Note: the DKIM Signing Complete Practice seems to
         be a pre-requisite for this Expectation]

    7.   [PROVISIONAL] A domain MUST be able to delegate responsibility
         for signing its messages to a non-related domain in such a way
         that it does not require active participation by the non- 
related
         domain.  That is, the published information MUST have a way to
         list Designated Domains that are authoritative for the First
         Party Address and are therefore allowed to sign on its behalf.

    8.   Practices and Expectations MUST be presented as an information
         service from the sender to be consumed as an added factor to  
the
         receiver's local policy.  In particular a Practice or
         Expectation MUST NOT specify any particular disposition stance
         that the receiver should follow.

    9.   If the Discovery process would be shortened by publication of a
         "null" practice, the protocol SHOULD provide a mechanism to
         publish such a practice.

         [INFORMATIVE NOTE: there seems to be widespread consensus  
that a
         "neutral" or "I sign some mail" practice is useless to
         receivers.  However, a null practice may help to cut short the
         policy lookup mechanism if it's published, and if that the case
         it seems worthwhile.  Also, a null policy may have some  
forensic
         utility, such as gaging the number of domains considering/using
         DKIM for example.]

    10.  The Protocol is not required to publish a Practice of any/all
         unrelated third parties that MUST NOT sign on the domain
         holder's behalf.

         [INFORMATIVE NOTE: this is essentially saying that the protocol
         doesn't have to concern itself with being a blacklist
         repository.]

    11.  The Protocol MUST NOT be required to be invoked if a valid  
first
         party signatures is found.

    12.  [PROVISIONAL] A signature that is not on behalf of the
         [RFC2822].From MUST NOT be construed as suspicious for the
         purposes of The Protocol.

    13.  [PROVISIONAL] A domain holder MUST be able to publish a  
Practice
         which enumerates the acceptable cryptographic algorithms for
         signatures purportedly from that domain.

         [INFORMATIVE NOTE: this is to counter a bid down attack; some
         comments indicated that this need only be done if the algorithm
         was considered suspect by the receiver; I'm not sure that I've
         captured that nuance correctly]

-Doug