Subject: [ietf-dkim] draft-ietf-dkim-base-09 submitted

From: Eric Allman <[email-masked]>
Date: Sun, 11 Feb 2007 10:15:04 -0800

I have submitted draft-ietf-dkim-base-09 for publication.  As with 
-08, the changes are all responses to IESG comments.  Unfortunately I 
don't think we are quite done yet --- we don't yet have 
acknowledgement that this version addresses all of the "discuss" 
items.  The changes are summarized in Appendix F.1.

  http://www.neophilic.com/~eric/DKIM/draft-ietf-dkim-base-09.txt
  http://www.neophilic.com/~eric/DKIM/draft-ietf-dkim-base-09.html

eric

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

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 12 Feb 2007 04:01:39 +0100

Eric Allman wrote:

> the changes are all responses to IESG comments.

I've certainly no clue what an "ASCII art attack" is (3.4.4).
 
> http://www.neophilic.com/~eric/DKIM/draft-ietf-dkim-base-09.txt

Here's an URL to create a diff: http://tinyurl.com/yql8lr

There's a "non-normative discussion point" in 3.6.1, you
can probably remove it now (?)
  
In 7: s/have documented/are documented/ or "have been" (?)

Frank

---

From: Douglas Otis <[email-masked]>
Date: Sun, 11 Feb 2007 19:51:38 -0800

,---
|8.13.  Inappropriate Signing by Parent Domains
|
|The trust relationship described in Section 3.8(Signing by Parent 
|Domains) could conceivably be used by a parent domain to sign messages
|with identities in a subdomain not administratively related to the 
|parent. For example, the ".com" registry could create messages with 
|signatures using an "i=" value in the example.com domain. There is no 
|general solution to this problem, since the administrative cut could 
|occur anywhere in the domain name. For example, in the domain
|"example.podunk.ca.us" there are three administrative cuts
|(podunk.ca.us, ca.us, and us), any of which could create messages with
|an identity in the full domain.
|
|  INFORMATIVE NOTE: This is considered an acceptable risk for the same
|  reason that it is acceptable for domain delegation. For example, in 
|  the example above any of the domains could potentially simply 
|  delegate "example.podunk.ca.us" to a server of their choice and
|  completely replace all DNS-served information. Note that a verifier
|  MAY ignore signatures that come from an unlikely domain such as
|  ".com", as discussed in Section 6.1.1(Validate the Signature Header
|  Field).
'---

Is automatically assuming all parent domains to be authoritative or that
large scale domain delegations and private key exchanges represent
acceptable risk?

This is wrong from both a security and a cost standpoint.

Is it really acceptable to have ad agency's MTA's contain private keys
for perhaps thousands of their clients?  Why is this risk acceptable
when it is unnecessary?  How can a verifier know whether to ignore
messages signed by "com" or perhaps "tokyo.jp"?  Who will publish the
now "unlikely" domains list?

DKIM can help reduce unwanted emails by _always_ having the entity
transmitting and signing messages publish keys within their _own_
domain.  DKIM signatures are not seen by the recipient, so there is
little justification for having signing domains always match that of
some email-address domain.  It is a simple matter for a domain contained
within a message to publish a record that authorizes the signature when
these domains differ.

The existence of a leaf can represent a sha1/base32 authorization of
"isp.com", for example. 

 hgssd3snmi6635j5743vdjhajkmpmfif._DKIM-F.example.com.

"isp.com" could use dedicated domains for particular customers, such as
"cust-0894.isp.com".  Use of customer specific sub-domains would isolate
their customer's authorizations without key exchanges or DNS
delegations.  There is no need for DNS domain delegations, private key
exchanges, or the assumption that all parent domains are authoritative.

DKIM signatures should indicate on who's behalf the message is signed,
even when domains differ.  This would minimize DoS risks by eliminating
any hunting for authorizations.  It should not automatically be assumed
the recipient wishes to only trust the From header, nor that a valid
signature always assures the validity of a From header source.  In the
case of a mailing-list, the Sender header might be trusted and assured
instead.

DKIM signatures are also likely to suffer from replay abuse.
Authorization of SMTP clients can bypass anti-replay protections, as
might be needed when DKIM is used for white-listing purposes.

An authorization scheme can easily accommodate multiple signing domains.
The DKIM base should be able to accommodate multiple email-address
identities within the DKIM signature.  This flexibility is needed to
deal with EAI extensions, and is easily supported by an originating
domain authorization scheme.

Allowing an authorization scheme to be safely used with the DKIM base
requires fairly minor changes to the base draft.  Importantly, these
changes remove the need for DNS delegations, private key exchanges, and
the assumptions that parent domains are authoritative. 

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 12 Feb 2007 09:45:26 +0000

> I've certainly no clue what an "ASCII art attack" is (3.4.4).

Relaxed reduces runs of whitespace to one space. Say you have
a message with loads of spaces on the left of a line, with the
non-whitespace message (some spamtext) off to the right of the
screen. Now if you can get that signed (say via some bounce
processor or whatever), then you can remove those runs of
whitespace and have a viewable spam,e.g. "B U Y E LL ER MAN N".
I'm sure there're loads of variants.

Not a very compelling attack, but the feeling from IESG
comments was that adding the warning was useful enough.

Cheers,
S.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 12 Feb 2007 11:47:48 -0800

On Feb 12, 2007, at 1:45 AM, Stephen Farrell wrote:

> Relaxed reduces runs of whitespace to one space. Say you have a  
> message with loads of spaces on the left of a line, with the non- 
> whitespace message (some spamtext) off to the right of the screen.  
> Now if you can get that signed (say via some bounce processor or  
> whatever), then you can remove those runs of whitespace and have a  
> viewable spam,e.g. "B U Y E LL ER MAN N".  I'm sure there're loads  
> of variants.
>
> Not a very compelling attack, but the feeling from IESG comments  
> was that adding the warning was useful enough.

This is a bad example.  Injected spaces can occur only where a  
whitespace (Space or HTAB) already existed as these are collapsed  
into a single whitespace during canonicalization.

A bad actor can introduce added spaces between words, where when  
viewed, spell something where words then act as as type of large  
pixel element.  There might be messages which better lend themselves  
to such an attack, but even this message could be mangled to say  
something unexpected.  This allows plausible deniability as well.  I  
never revealed the name of his wife...  : )

-Doug