Subject: RE: [ietf-dkim] Base issue: multiple linked signatures

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 4 Jan 2007 11:18:33 -0800

> [mailto:[email-masked]] On Behalf Of Scott Kitterman

> While there is certainly nothing an RFC can do to prevent 
> receivers from attempting to do the kind of message reverse 
> engineering being discussed, the current MUST NOT wording 
> makes it clear that the results of that processing are not 
> part of the protocol.  Receivers can guess all they want, but 
> don't call the result of that effort a DKIM result.  

If you want to state that something is not part of the protocol you should use SHOULD.

The rules are very clear, MUST can only be used in cases when breaking the rule will inevitably produce incompatibility. 

Speculation that breaking the rule might produce incompatibility is not enough. RFC 2119 is very clear. 

We can debate whether this behavior is a good idea or not. What we can't do is to state that we are using the definitions of MUST and SHOULD from 2119 and then use our own private definitions because we think we know better.

Incidentally does RFC 2119 make Scott the most cited author in the field? I suspect so since it is cited in practically every OASIS and W3C standard as well.

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

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 4 Jan 2007 14:38:12 -0500

On Thursday 04 January 2007 14:18, Hallam-Baker, Phillip wrote:

> The rules are very clear, MUST can only be used in cases when breaking the
> rule will inevitably produce incompatibility.
>
>

>From my perspective having a message have a valid signature with one 
implementation and having a broken signature with another is an 
incompatibility.  I don't think that's speculation.  I think it's the clear 
and obvious result of trying to reconstruct the original content and seeing 
if a valid signature can be extracted based on a process not specified.

I think what we are discussing here qualifies as an incompatibility.

Scott K

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 05 Jan 2007 10:36:25 -0000

> if a valid signature can be extracted based on a process not specified.

No, it merely reflects a difference of opinion by the sites concerned as  
to what changes it will tolerate in a message before it recommends to its  
clients that the message should be dropped. It is not the job of our  
standard to dictate local policy issues at that level of detail.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 5 Jan 2007 11:04:42 -0000

>> incompatibility.  I don't think that's speculation. ...

>standard to dictate local policy issues at that level of detail.

I agree that we are not dictating local policy.  But I really think that
it's our job to dictate the definition of what the signature validation
algorithm is.  As I've said before, everyone remains free to do whatever
they want with messages whether or not the signature verifies, including
applying various heuristics to develop opinions about unsigned messages.

R's,
John

---

From: [email-masked] (Wietse Venema)
Date: Fri, 5 Jan 2007 07:51:50 -0500 (EST)

> applying various heuristics to develop opinions about unsigned messages.

Perhaps some people are confusing verification and presentation.

Verification: it is critical that all DKIM verifiers agree on what
is a valid DKIM signature, without falling back on heuristics, such
as heuristics to repair messages.

Presentation: after the valid/invalid decision is irevocably made,
it is up to application/policy to decide how/if things will be
presented to users.  Heuristics of various sorts can be useful in
this domain, such as message repair, known signer associations,
etc., but those heuristics must not determine the validity of the
DKIM signature.

	Wietse

---

From: Michael Thomas <[email-masked]>
Date: Fri, 05 Jan 2007 09:35:34 -0800

> etc., but those heuristics must not determine the validity of the
I really don't understand all of this hand wringing about True Verification
vs. Mutant Verification Intent on Taking Over Earth. The protocol document
needs to be precise about what it takes for a properly written verifier to
verify a properly signed message. That's it. Trying to make normative any
or all of the ways _not_ to verify a signature is not only a waste of 
time, it's
a hopeless task. Having informative text to guide implementors with
potentials gotchas, corner cases, and other possible misinterpretations 
is fine
to a point, but making them _normative_ makes no sense whatsoever.

       Mike

---

From: <[email-masked]>
Date: Fri, 5 Jan 2007 13:02:15 -0500

+1

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Michael Thomas
Sent: Friday, January 05, 2007 12:36 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [ietf-dkim] mutant message validation, was Base issue:
multiplelinked signatures

> etc., but those heuristics must not determine the validity of the
I really don't understand all of this hand wringing about True
Verification
vs. Mutant Verification Intent on Taking Over Earth. The protocol
document
needs to be precise about what it takes for a properly written verifier
to
verify a properly signed message. That's it. Trying to make normative
any
or all of the ways _not_ to verify a signature is not only a waste of 
time, it's
a hopeless task. Having informative text to guide implementors with
potentials gotchas, corner cases, and other possible misinterpretations 
is fine
to a point, but making them _normative_ makes no sense whatsoever.

       Mike

---

From: Hector Santos <[email-masked]>
Date: Fri, 05 Jan 2007 13:45:21 -0500

> etc., but those heuristics must not determine the validity of the

MAJOR +1!!

For me, there needs to be a reason to add DKIM verification. Signing 
might come afterwards after we see how VERIFICATION works.   I prefer 
not to get into the "labeling" game, either the purported DKIM message 
is acceptable or not.  This is why we need to get the "SSP" concept 
squared away because I am afraid that too much failures will hurt DKIM 
ultimate wide adoption.   I am still convince that most people are not 
going to sign mail if the ROUTE it takes is proven to break the 
integrity of the mail.  So DKIM will be mostly benefitial atleast at the 
early state for specific routes, mostly 1 to 1 routes.  But thats my 
opinion.

---
HLS

---

From: Douglas Otis <[email-masked]>
Date: Fri, 5 Jan 2007 18:42:53 -0800

On Jan 5, 2007, at 10:45 AM, Hector Santos wrote:

> I am still convince that most people are not going to sign mail if  
> the ROUTE it takes is proven to break the integrity of the mail.

This is a reason to remove from the DKIM base draft the 5.4  
stipulation that the From header MUST be signed.  After all,  
internationalization is likely to cause invalid signatures.  When  
other headers might actually represent the signing-originator, it  
makes little sense for this stipulation, when this then requires  
heuristics to "save" the signature.  This 5.4 statement could be  
changed to indicate that an originating header SHOULD be signed.

Although I am sure your concern is focused upon verification at the  
MTA, protection afforded by DKIM allows the MDA-MUA path to not be  
trusted.  Perhaps at some point a new identity could be included  
within the signature to ensure a discernible linkage between the  
originating header and the signer.

Introducing restrictive policy will only further diminish the success  
rate of otherwise legitimate messages when other headers are not  
accommodated.

Policy that establishes associations with other domains also supports  
opportunistic security, as used with protocols likes SSH.  When the  
goal is to improve the integrity of mail, allowing autonomous  
associations accommodating all headers offers the only solution that  
may make a genuine improvement.  The base draft's requirements that  
specific headers be signed, and that any header linkage is only  
discernible when domains match creates impediments for the success  
rate of legitimate mail.  These dubious requirements are aimed at  
supporting visual recognition, which is perhaps worse than misleading.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Jan 2007 07:33:04 -0800

> -----Original Message-----
From: Michael Thomas

Wietse Venema wrote:
 > verify a properly signed message. That's it. Trying to make normative any or
 > all of the ways _not_ to verify a signature is not only a waste of time, it's
 >  a hopeless task.

Mostly +1.

In line with Wietse, we need to distinguish between two, basic activities.  One 
is verification.  I would call the other "interpretation", rather than 
"presentation" because it is a function of the filtering agent -- and can result 
in a variety of handling outcomes -- rather than just presentation to the user.

The fundamental point is that dkim-base defines how to create a signature and 
how to validate a signature.  Anything done after the basic, interoperable, 
yes/no validation is outside the scope of -base.

Calling it "policy" is a good way of distinguishing it from the scope of -base 
which is intended to be purely mechanism.

d/

-- 

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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 10 Jan 2007 14:01:41 -0800

On Jan 10, 2007, at 7:33 AM, Dave Crocker wrote:
>> Verification vs. Mutant Verification Intent on Taking Over Earth.  
>> The protocol document needs to be precise about what it takes for  
>> a properly written verifier to verify a properly signed message.  
>> That's it. Trying to make normative any or all of the ways _not_  
>> to verify a signature is not only a waste of time, it's a hopeless  
>> task.
>
> Mostly +1.
>
> In line with Wietse, we need to distinguish between two, basic  
> activities.  One is verification.  I would call the other  
> "interpretation", rather than "presentation" because it is a  
> function of the filtering agent -- and can result in a variety of  
> handling outcomes -- rather than just presentation to the user.
>
> The fundamental point is that dkim-base defines how to create a  
> signature and how to validate a signature.  Anything done after the  
> basic, interoperable, yes/no validation is outside the scope of -base.
>
> Calling it "policy" is a good way of distinguishing it from the  
> scope of -base which is intended to be purely mechanism.

The base draft requires the From header be signed.  This header might  
become modified for EAI compliance.  One mode of verification might  
therefore always include header copies to allow DKIM verification to  
remain robust.  It may be better to anticipate that From header may  
_not_ play a significant role in the validation/anti-spoofing  
process.  Instead, perhaps an EAI style identity might be placed  
within the DKIM signature.  Validation could then include a means to  
confirm associations between domains when they differ from what is  
found within a specific header.  In addition, the originating header  
is not always going to be the From header, where EAI fix-ups will  
require added heuristics without tangible benefit.

The alternative associative approach also eliminates a need to share  
private keys in some fashion.  While DNS zone delegation or CNAME  
arrangements at specific key leafs might be seen as a workable  
solution, either of these schemes require detailed coordination  
between at least two parties.  This level of coordination will  
needlessly increase costs associated with DKIM, and thus make DKIM  
less practical in many situations.

An associative scheme with the sending entity would allow these  
sending entities to better protect reputations of outbound servers.   
It would also permit the email-address domains owners an autonomous  
means to opportunistically take advantage of DKIM signing.  When a  
provider signs within sub-domains unique for each organization  
serviced, then such a scheme would also assure that associations  
would not open the door for spoofing.  This approach avoids private  
key sharing, DNS delegation, and the use of CNAMEs that is unlikely  
to prove practical.  An associative scheme would incur the same  
overhead as that of a CNAME as well, and more easily accommodate use  
of other headers reflecting the entity introducing the message.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 10 Jan 2007 17:19:13 -0500

On Wednesday 10 January 2007 17:01, Douglas Otis wrote:

> become modified for EAI compliance.  

We've been through this before.  IIRC, we included 2822-From because it's a 
mandatory part of the message.  If you don't sign it, you didn't sign the 
message.  We don't sign every other line of the body either.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Wed, 10 Jan 2007 18:54:20 -0800

> message.  We don't sign every other line of the body either.

At that time, it was less clear the impact of that decision.  What  
value exists when the From header is not associated with the signing- 
domain?  This again mistakenly assumes recipients will verify the  
originator based upon visual inspection.  What happens when there are  
EAI fix-ups on messages sent through a mailing list that signs their  
messages?  This requirement will cause these signatures to fail for  
no valid reason.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 10 Jan 2007 22:52:07 -0500

> messages?  This requirement will cause these signatures to fail for

IIRC we discussed EAI at the time and it's not clear to me that anything's 
changed.  This has nothing to do with the originator address and everything 
to do with signing the required elements of the message.

Taken to an extreme, there are reasons why any part of the message might get 
changed and so we ought not sign anything.  

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Thu, 11 Jan 2007 02:07:27 -0800

On Wed, 2007-01-10 at 22:52 -0500, Scott Kitterman wrote:
> [Must sign the From header.]
>
> This has nothing to do with the originator address and everything to
> do with signing the required elements of the message.
> 
> Taken to an extreme, there are reasons why any part of the message
> might get changed and so we ought not sign anything.  

Robust signatures are needed to abate criminal spoofing of originators
and to be utilized for ensuring abuse feedback and DSNs.

The agent transmitting the message might not be represented by From
header. In the case of a mailing list, the Sender header is likely
associated with the signing domain.  A mailing list signing the From
header reduces robustness of the signature for little benefit.  The
signature should clarify which identity the message is being signed on
behalf of, as this likely represents who is being trusted. 

When the signature is permitted to carry the "Identity of the user or
agent (e.g., a mailing list manager) on behalf of which this message is
signed" _without restriction_, there would be far less reason to sign
associated headers.

A valid signature is never apparent to the recipient without annotation.
Annotate headers containing "trusted" identities associated with valid
signatures.  Even when this header is signed, the Display-Name will not
have been verified as being associated with the signing-domain.  As
such, the recipient should place little trust in the Display-Name.

The Identity could be in the form of <UTF-8@UTF-8 <ASCII@ASCII>>.  ASCII
and UTF-8 domains may not be equivalent or match that of the signing
domain.  With a method to confirm that either the UTF-8 or the ASCII
domain is associated with the signing-domain (even when they differ),
then all is well without the header having been signed.  There would be
little point in annotating associated identities without the identity
being trusted or digitally recognized.

-Doug

---

From: "david" <[email-masked]>
Date: Fri, 12 Jan 2007 23:48:11 -0600

Hi All,
Just a basic question here. I've gone over the DKIM spec, but can anyone
tell me where the original Yahoo Domainkeys spec is at? Since DKIM is still
in a state of flux, I want to just fully implement the orignal DomainKeys
spec.

Thanks!
David

---

From: Gino Cerullo <[email-masked]>
Date: Sat, 13 Jan 2007 07:42:46 -0500

> in a state of flux, I want to just fully implement the orignal  

I don't know about the spec per se, but an awful lot of information  
is available right here,

http://antispam.yahoo.com/domainkeys

Might be a good starting point for you.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 13 Jan 2007 17:50:18 +0100

david wrote:

> can anyone tell me where the original Yahoo Domainkeys spec is at?

http://tools.ietf.org/html/draft-delany-domainkeys-base

Get it quick, it expires in 11 days... <joke />

> Since DKIM is still in a state of flux

Not really, only the SSP part.  Compare

https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=2245

Frank

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Jan 2007 09:06:27 -0800

>> in a state of flux, I want to just fully implement the orignal DomainKeys

DKIM is not 'in a state of flux'.

The <http://dkim.org> web page has listed a stable specification for nearly 2 
years (well, certainly more than 1.)  It also cites a number of existing 
implementations.

In addition, the IETF working group effort at revisions has completed, except 
for final approval from the IESG. Any changes from the previous, stable draft s 
are upward compatible.

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Wed, 17 Jan 2007 10:18:32 -0800

> DKIM is not 'in a state of flux'.

DKIM's restrictions on linking signatures with a header was premised  
upon an expectation that visual examination of headers provided a  
means for recognition.   When the entire email-address is expressed  
in UTF-8 (SMTP is in a state of flux), DKIM verifiers may be unable  
to handle domain conversions from UTF-8.  Will a header display the  
UTF-8 version of the email-address while the DKIM verification checks  
what might be an ACE label form of the email-address?  Will DKIM  
require regressive substitutions of headers in an effort to restore a  
signature, or will this represent a high failure rate for DKIM signed  
messages?  Will DKIM require extensive exchanges of private-keys or  
zone delegations as the _only_ method of overcoming the linkage  
restriction where email-address domains must be within signing  
domains?  While DKIM may not be in a state of flux, SMTP is.  The  
premise used to instantiate  restrictions on the identity on who's  
behalf the signature was added remains flawed and increasingly so.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 17 Jan 2007 13:39:48 -0500

On Wed, 17 Jan 2007 10:18:32 -0800 Douglas Otis <[email-masked]> 
wrote:
>means for recognition.   

Would you please point me to a reference for this statement?  

I recall saying 2822.From should be signed because it's a mandatory element 
of an e-mail message.  You seem to remember a different WG discussion than 
I do.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Fri, 19 Jan 2007 11:14:15 -0800

> of an e-mail message.  You seem to remember a different WG  

Here is the base draft description of use based upon annotation:
---
Appendix C.
...
The MUA may choose to highlight, accentuate, hide, or otherwise
display	any other information that may, in the opinion of the MUA
author, be deemed important to the end user.
---

To better understand the signature selection process, the basis is  
the trusted email-address as clearly indicated in the newly added text.

---
4.1
...
				
Another related example of multiple signers might be forwarding			
services, such as those commonly associated with academic alumni			
sites.			
				
INFORMATIVE EXAMPLE: A recipient might have an address at			
alumni.example.edu, a site that has anti-abuse protection that is			
somewhat less effective than the recipient would prefer. Such a			
recipient might have [specific authors] whose messages would be			
trusted absolutely, but messages from unknown authors which had			
passed the forwarder's scrutiny would have only medium trust.

4.2
...
When evaluating a message with multiple signatures, a verifier  
SHOULD	 		
evaluate signatures independently and on their own merits. For			
example, a verifier that by policy chooses not to accept signatures			
with deprecated cryptographic algorithms would consider such			
signatures invalid. Verifiers MAY process signatures in any order of			
their choice; for example, some verifiers might choose to process			
[signatures corresponding to the From field] in the message header			
before other signatures. See Section 6.1 for more information about			
signature choices.
---

So how is the signature confirmed to correspond with the From header  
when ALL signatures must include the From header?  The answer is that  
the contained email-address MUST be within the domain of the DKIM  
signature.  Ask yourself why this restriction was imposed.  This will  
mean that a large email provider's outbound servers may contain  
thousands of other domain's private keys!  How quickly can all those  
domains recover from a breach in this server's security when each  
change might require the coordination of more than two entities?  Who  
signed the message will be what recipients will want to know, but  
they will also need to know which Selector was used for each of the  
many different domains.  What a complete and utterly ridiculous mess!

The far safer alternative would be to allow the DKIM signature to  
clearly indicate on who's behalf the signature was being applied,  
irrespective of the email-address's domain.  This would allow the  
verifier to weed through what might be a mess of signatures and  
thereby avoid DDoS exploits.  When desired, allow the email-address  
domain to associate with the signing domain, perhaps by using a SHA1/ 
base32 tag of the signing domain. (Same overhead as a CNAME.)  If a  
server becomes compromised, only one private-key is compromised, and  
the users of that service can quickly and autonomously respond  
without needing to coordinate these changes to restore security.  The  
security update report will only need to list the one domain that was  
compromised and not thousands with all their respective Selectors.   
Why should DKIM be allowed to make MTAs such a high level security risk?

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 19 Jan 2007 21:50:44 +0100

Douglas Otis mentioned:

> alumni.example.edu

s/edu/org/ or s/edu/net/  RFC 2606 doesn't cover TLD edu.

Frank

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 19 Jan 2007 13:04:13 -0800 (PST)

> s/edu/org/ or s/edu/net/  RFC 2606 doesn't cover TLD edu.

True, but I believe the operator of the .edu registry has committed to 
example.edu being handled in the same way as example.org and example.com 
(ie, not ever being assigned to anything real).  So, OK to use for 
examples if desired to do so; we in .edu circles do it all the time.

  - RL "Bob"

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 20 Jan 2007 03:03:21 +0100

RL 'Bob' Morgan wrote:

>> RFC 2606 doesn't cover TLD edu.

> True, but I believe the operator of the .edu registry has committed
> to example.edu being handled in the same way as example.org and
> example.com (ie, not ever being assigned to anything real).  So, OK
> to use for examples if desired to do so

Unfortunately that's not the case in most TLDs, and users try it
anyway inspired by examples as in the DKIM draft, and that causes
havoc for the owners of real example / test / invalid domains.

Therefore I think it's NOT okay until RFC 2026 is updated, or until
a TLD specific policy RFC guarantees that it's okay.

> we in .edu circles do it all the time.

The issue isn't that it happens to work as expected in TLD edu at the
moment, the problem are clueless users trying this approach elsewhere.

Frank