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

From: DKIM Chair <[email-masked]>
Date: Tue, 26 Dec 2006 11:21:09 -0500

In discussions with the IESG to sort through their "discuss" comments, 
I had a talk with Lisa Dusseault, and she had one point that I want to 
bring back to the mailing list:  I don't think we considered, in our 
discussions of multiple signatures, multiple *linked* signatures, which 
could work TOGETHER to convey information, and the protocol doesn't 
allow that sort of thing.  The way dkim-base is set up, I don't think 
this could easily be added as an extension, and it'd be a significant 
change at this point.  Here's the concept:
* Signer puts on two signatures (maybe as two header records, maybe as 
one that contains two sigs).
* One of the signatures has minimal scope, maybe signing only "from:", 
with l=0.
* The other signature covers as much of the message as possible... most 
headers, all the boby.
* The two signatures work together.  If one verifies and the other 
doesn't, the verifier can consider what was changed in the message, and 
possibly use that information to deal with mailing list modifications 
or whatnot.

One way this might be used is to have one signature that covers the 
subject header and one that doesn't, to allow the verifier to detect a 
subject change and decide whether it's OK.  As the spec is now, the 
verifier would just find the one signature (that doesn't cover the 
subject) that works, and use that, not considering the other.

The WG did discuss related things, so maybe we'll decide that this was 
covered and dismissed, but it's a wrinkle that I want to make sure we 
look at.  Let's beat this around for a week or so, and see where we are 
with it, and what we do or don't want to do with it.

Barry

--
Barry Leiba, DKIM working group chair  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Dec 2006 08:36:39 -0800

DKIM Chair wrote:
> discussions of multiple signatures, multiple *linked* signatures, 
> which could work TOGETHER to convey information, and the protocol 
> doesn't allow that sort of thing.  The way dkim-base is set up, I 
> don't think this could easily be added as an extension, and it'd be a 
> significant change at this point.  Here's the concept:
> * The other signature covers as much of the message as possible... 
> most headers, all the boby.
> doesn't, the verifier can consider what was changed in the message, 
> and possibly use that information to deal with mailing list 
> modifications or whatnot.
>
> look at.  Let's beat this around for a week or so, and see where we 
> are with it, and what we do or don't want to do with it.
One can already do this by copying the relevant headers into the signature
using z=. I already do this and it works just fine for mailing lists. 
Since it
involves a whole boat load of heuristics, I don't think it really belongs in
the base spec which should, IMO, just define the mechanics of the protocol.
Whether we wanted to outline such strategies in a BCP seems like a 
reasonable
question though.

       Mike

---

From: Dave Crocker <[email-masked]>
Date: Tue, 26 Dec 2006 09:00:26 -0800

Barry,

DKIM Chair wrote:
> In discussions with the IESG to sort through their "discuss" comments, I 
> had a talk with Lisa Dusseault, and she had one point that I want to 
> allow that sort of thing.  
...
> look at. 

On the other hand...

It would not take very much effort to describe quite a few scenarios that the 
current specification does not cover, and possibly has no obvious way to cover. 
  (For some months, I have known of at least one real-world need that isn't 
covered, for example.)

We are not going to anticipate every theoretical or every actual need, and the 
requirement for linked signatures has not been stated before, by the 
constituency that is seeking to actually *use* DKIM.

There is, therefore, a basic question:  Why should a stable specification, for 
which working group consensus has been reached, be required to pursue such a 
topic at this stage?

Yes, I understand that an AD has a Discuss and that that's important.  But it 
does not mean that it is a legitimate basis for declaring that the working group 
must consider usage goals for which there has been no expressed need.

I therefore suggest that the working group politely decline to pursue this scenario.

d/
-- 

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

---

From: Hector Santos <[email-masked]>
Date: Tue, 26 Dec 2006 12:21:28 -0500

I don't think this can resolved until SSP is resolved and in many 
respect, this Linked Signature concept is related to SSP.

Quick examples:

1) Multiple signatures, linked or not linked, may be meaningless for 
strong/exclusive domain signature policies where 3rd party signings 
and/or mail "integrity issues" are not expected expressed via SSP.

2) Linked Multiple signatures allowed and expected by the primary domain
expressed via SSP.

etc.

In short, the primary domain must allow for its mail to be used in ways 
it might expect it to be used.

Just consider the possible decision process:

               1st party     2nd party   Linked?     Result

  VALID           YES          YES        YES        VALID
  VALID           YES          YES        NO         VALID?

  VALID           YES          NO         YES        INVALID???
  VALID           YES          NO         NO         INVALID?

  VALID           NO           YES        YES        VALID??
  VALID           NO           YES        NO         INVALID???

  VALID           NO           NO         YES        INVALID?
  VALID           NO           NO         NO         INVALID

To me, if the 1st party fails, then nothing else matters. But that might 
depend on the SSP where there be a Linked Signature Requirement 
attribute or flag.

Please keep in my mind that there needs to be a "benefit" or "payoff" 
for a wide adoption of verifiers to take place. Even of a system does 
not initially adopt SIGNING of mail, we might find that VERIFIERS might 
indeed be adding first verification before adding signing to the 
process.   The payoff needs to be shown via VERIFICATION first IMO.

---
HLS

DKIM Chair wrote:
> possibly use that information to deal with mailing list modifications or 
> whatnot.
>

---

From: Hector Santos <[email-masked]>
Date: Tue, 26 Dec 2006 12:45:34 -0500

Dave Crocker wrote:
 > ....
> There is, therefore, a basic question:  Why should a stable 
> specification, for which working group consensus has been reached, be 
> required to pursue such a topic at this stage?

Because, by far, there are going to be TWO general cases:

    - Strong/Exclusive Domain Signatures scenarios
    - Mailing List or 3rd party distribution scenarios

and we spent a lot of time wondering how to resolve the latter when in 
fact, we all know there is going to be, a somewhat Natural expectation, 
of HIGH potential invalid signatures due to mail integrity issues.

We all know the exclusive will work in its direct emailing capacity, and 
by some, maybe too good or too strong in that it can break "certain 
kinds" of 3rd party distributions. But to me, that to me a desired 
feature and not a show stopper.

What is the show stopper is seeing a vast 3rd party DKIM distribution 
where the majority of the signings are invalid.  So it will always be 
interesting to see how we can best address it.

> I therefore suggest that the working group politely decline to pursue 

Unless there is a solid solution to this, I agree with you that it 
probably isn't worth pursuing.

OTOH, I still think SSP is the required and "easy" technology to answer 
many of the DKIM signature "Domain Mail Expectation" questions and I 
think SSP is related and also covers this "link signature" concept.

---
HLS

---

From: wayne <[email-masked]>
Date: Tue, 26 Dec 2006 11:49:43 -0600

> * One of the signatures has minimal scope, maybe signing only "from:",

Please pardon my ignorance here, as I haven't not been following this
group closely lately, but...

Wouldn't signing just the 2822.From: header be close to useless since
it could trivially be replayed on all forged email?  Even if you throw
in things like the 2822.Message-ID:, and 2822.Date:, etc., you really
have more "security" with the Habeas haiku.

-wayne

---

From: John Levine <[email-masked]>
Date: 26 Dec 2006 18:22:08 -0000

> doesn't allow that sort of thing.

We have certainly beaten to death the issue of whether signatures can
or should survive mailing lists, an aspect of the underlying argument
about whether a list is an endpoint or a forwarder.  I think we can
all agree this is not an argument we're going to resolve any time
soon.

I don't understand what the security model of linked signatures would
be, and I doubt anyone else does, either.  Since DKIM allows multiple
signatures now, and allows you to put private fields in the signature
header, there's plenty of tools available for people to experiment,
and if the experiments pan out, add linking in DKIM N+1.  But it
strikes me as a poor idea to make a change this basic on short notice
at this late date..

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 26 Dec 2006 10:41:02 -0800

> one that contains two sigs).

There is a situation that could lead to a DoS related to multiple
signatures.  This problem would be in conjunction with a discovery
process checking associations of an email-address with that of a list of
signatures contained within a message.  The signature itself offers
little assistance in determining which email-address induced the
signature when the signing-domain differs from that of the email-address
domain.

Lack of assistance in a signature selection process in this case is due
to a limitation placed upon the 'i=' syntax.  This syntax can be
upwardly changed to allow explicit associations asserted between an
email-address-in-question and any signature.  It will remain apparent
when the email-address domain and the signing-domain differ.  With older
implementations, such a signature will be invalid and ignored.

The basis for the 'i=' syntax limitation assumes policy blocks messages
not signed by a parent domain.  This concept is based upon visual
recognition and remains highly flawed for many reasons.  Once MUA
"recognition" of email-addresses based on Address-Books or trusted lists
is used, then extending the 'i=' syntax makes a great deal of sense.
Having the MUA preform verification also overcomes requiring a trust
relationship between the MDA and the MUA, while also thwarting common
look-alike attacks.

>   most headers, all the body.

There is also the body hash that can provide a similar function.  The
use of multiple signature will likely occur, but not for this reason.
At least there should not be any valid reason for using the 'l=0'
parameter. 

> subject) that works, and use that, not considering the other.
 
A change to the limitations on the 'i=' syntax could clarify the
specific role of the signature, and prevent various DoS exploits that
might attempt to overload the resource intensive validation process.  An
'i=' syntax change would be beneficial when validations are limited to
"recognized" email-addresses.  Such a change would limit the number of
bogus signatures checked.  As it is now, any or all signatures would
need to be evaluated for a possible relationship.  Header ordering
should not be assumed.

This issue will prove more significant when the MUA or MDA is used to
annotate "recognized" messages.  Annotation is the only method where
recipients are offered protection by DKIM.  Allowing the email-address
domain and the signing-domain to differ also retains the normal use of
email.  Without there being any correlation between the signing-domain
and the transmitting entity, abuse-reporting will be far less useful.

Before DKIM improves upon email integrity, an ability to associate
various email-originating domain with that of the signing-domain still
needs to be developed.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 26 Dec 2006 10:45:41 -0800

At 11:21 AM -0500 12/26/06, DKIM Chair wrote:
>In discussions with the IESG to sort through their "discuss" 
>comments, I had a talk with Lisa Dusseault, and she had one point 
>that I want to bring back to the mailing list:  I don't think we 
>considered, in our discussions of multiple signatures, multiple 
>*linked* signatures, which could work TOGETHER to convey 
>information, and the protocol doesn't allow that sort of thing.  The 
>way dkim-base is set up, I don't think this could easily be added as 
>an extension, and it'd be a significant change at this point. 
>Here's the concept:
>* Signer puts on two signatures (maybe as two header records, maybe 
>as one that contains two sigs).
>* One of the signatures has minimal scope, maybe signing only 
>"from:", with l=0.

I also discussed this with Lisa, and came to a very different conclusion.

What is being proposed above is that an additional signature be 
generated and validated for every "important" header. That is a huge 
waste of energy, and it will cause massive unnecessary resource 
usage, particularly for recipients who don't care why a signature 
might not have validated.

If the concern is "accidental" breakage, Michael's point is exactly right:

>using z=. I already do this and it works just fine for mailing lists.

If the concern is "purposeful" breakage, encouraging signers to sign 
messages covering only the From header and none of the body is 
incredibly bad. Wayne is exactly right:

>have more "security" with the Habeas haiku.

--Paul Hoffman, Director
--Domain Assurance Council
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: [email-masked]
Date: Tue, 26 Dec 2006 14:16:26 -0800 (PST)

> be, and I doubt anyone else does, either.

Considerable time was spent on the nested/linked/multiple signature issue
during the work that led up to the specification of security multiparts and
MOSS. We never got a handle on it either and it wasn't for lack of trying.

>  Since DKIM allows multiple

I emphatically agree. I will also note that a comparable set of tools are
provided by multipart/signed to MOSS (not that anyone cares about MOSS any
more), PGP, and S/MIME, and pretty much nothing has come of it. Maybe DKIM will
be different, but while I'm optimistic that DKIM will see better deployment,
that optimism doesn't extend to tricky stuff in this area.

				Ned

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 26 Dec 2006 16:34:24 -0600

I agree with the below.  There is already a means to determine what 
header change broke the signature (assuming a signer is interested in 
providing the necessary data) and assuming a verifier even cares.

-- 
Arvel

Paul Hoffman wrote:
> waste of energy, and it will cause massive unnecessary resource usage, 
> particularly for recipients who don't care why a signature might not 
> have validated.
>

---

From: Hector Santos <[email-masked]>
Date: Tue, 26 Dec 2006 18:01:25 -0500

> that optimism doesn't extend to tricky stuff in this area.

But its broken NOW (mailing list breaking DKIM integrity), out of the 
box, without getting any real DEPLOYMENT.  How much tricker can it get?

What is the solution for a MAIL SERVER Designer such as us?

Anyone with an answer?  Just resign even if the original signature is 
now broken?

---
HLS

---

From: EKR <[email-masked]>
Date: Tue, 26 Dec 2006 15:43:37 -0800

Paul Hoffman <[email-masked]> writes:

>> an extension, and it'd be a significant change at this point. Here's
>> the concept:
>> * The other signature covers as much of the message as
>> possible... most headers, all the boby.

I don't know what's being proposed here, but as a technical matter
it's not really the case that you can't individually insulate each
header from breakage without doing a separate signature for each
one. Rather, you could simply include digests for the header value in
the header specification, i.e.,

   DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane;
      c=simple; q=dns/txt; i=@eng.example.net;
      t=1117574938; x=1118006938;
      h=from=<digest-value>:to=<digest-value>:subject-<digest-value>:date=<digest-value>;
      ...

Again, I'm not offering an opinion on what should or should not be done
here, merely on what's possible.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 26 Dec 2006 15:57:11 -0800

>h=from=<digest-value>:to=<digest-value>:subject-<digest-value>:date=<digest-value>;

This is actually less information than the z= tag, which says what 
the value was when signed.

--Paul Hoffman, Director

---

From: EKR <[email-masked]>
Date: Tue, 26 Dec 2006 16:07:55 -0800

Paul Hoffman <[email-masked]> writes:

> This is actually less information than the z= tag, which says what the
> value was when signed.

Yes, that's true, so even without this optimization it's not true
that you need to a separate signature for each header.

That said, this representation is more compact, so it's a tradeoff. 

It also doesn't come with this restriction:

       Verifiers MUST NOT use the header field names or copied values
       for checking the signature in any way.  Copied header field
       values are for diagnostic use only.

But of course that restriction could be relaxed.

-Ekr

---

From: Dave Crocker <[email-masked]>
Date: Tue, 26 Dec 2006 16:13:03 -0800

> I don't know what's being proposed here, but as a technical matter

I believe Lisa has said she will post more specific details under her "discuss", 
so that we can be more clear about what she is seeking from the working group.

And she had indicated that some of her views and concerns have changed since she 
posted the existing comments, what with all of the conversations folks have been 
having with her.

Guessing the current details might be fun, but there is no reason to believe it 
would be productive...

d/

-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Tue, 26 Dec 2006 16:56:20 -0800

> here, merely on what's possible.

Insulation is not as important as assuring an association with the
signature thereby confirming the role being played.

With the current base specification, any email-address domain not within
the signing-domain can not explicitly indicate which email-address is
associated with the signature.  When these domains differ, finding an
association must then be trial and error.  To avoid a trail and error
process, there should there be a means to assert an association that
does not demand zone delegation or the exchange of private-keys.

To retain the current freedoms of choice for email-addresses, one should
consider the situation where the identity within the From header differs
from that of the signing-domain.  The current 'i=' syntax prevents this
association being explicit when these domains differ.

-Doug

---

From: John Levine <[email-masked]>
Date: 27 Dec 2006 01:23:39 -0000

>But of course that restriction could be relaxed.

My recollection is the point of that restriction is that a verifier
has to use the actual values of the headers in the message, not the
copied versions in the z= header.  There had been some suggestions
that if a header were "close enough" to the copied version, the
verifier might substitute in the copied version.  As always, this was
part of the mailing list argument, with the idea to have signatures
tolerate subject munging that lists like this one do.  We decided
against it both because nobody proposed a concrete version of close
enough, and because nobody could say how a verifier would distinguish
algorithmically between an inserted [ietf-dkim] and an inserted
[[email-masked]].

A perfectly legitimate diagnostic use on a failed signature is to
detect what header(s) don't match the copies, and whether the
signature would have verified had the current versions matched the
copied versions.  But I don't know what you'd do operationally once
you figured that out, and I don't recall any other suggestions that
didn't involve considerable hand waving.

> That said, this representation is more compact, so it's a tradeoff. 

You're right, but in an era when one line messages routinely contain
20K of HTML style goop, compact headers are the least of our worries.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Wed, 27 Dec 2006 10:48:28 -0800

On Dec 26, 2006, at 10:22 AM, John Levine wrote:

> I don't understand what the security model of linked signatures  
> would be, and I doubt anyone else does, either.  Since DKIM allows  
> multiple signatures now, and allows you to put private fields in  
> the signature header, there's plenty of tools available for people  
> to experiment, and if the experiments pan out, add linking in DKIM N 
> +1.  But it strikes me as a poor idea to make a change this basic  
> on short notice at this late date..

DKIM _only_ provides protection only when a "recognized" email- 
address domain demonstrates an association with that of the signing- 
domain.  This association might be viewed as "linking" signatures.   
There is nothing that would prevent making a rather minor change with  
the 'i=' syntax to greatly minimize the number of signatures that  
might need checking while hunting for an association (linkage).  This  
minor change would enable a path forward in a non-disruptive fashion.

When providers experiment and sign all email they transmit, they  
might expect DKIM signatures to afford better abuse-reporting, for  
example.  A profusion of signatures not matching any email-address  
within the message, and without any linkage offered that indicates  
the email-address being serviced by the signature,  could rapidly  
become a real mess once spammers also mimic this behavior.  A means  
to "link" the signature with some email-address is needed even when  
the domains differ.  Email-address recognition must serve as a basis  
for protective annotation, where some from of linkage is perhaps the  
only viable solution available.  When done by way of the 'i=' syntax,  
this linkage is also extremely simple, minor, and non-disruptive.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Thu, 28 Dec 2006 06:19:12 -0800

> But of course that restriction could be relaxed.
There's two ways to read this restriction: one is that you should
never do this under any conditions which ventures into silly net.cop
delusions of what the protocol document can mandate, and a more
innocent caution that the actual headers to be used for a dkim
verification are the outside headers, not the copied headers.

The latter is the only reasonable way to read this. I agree with
John that this is pretty well trod ground and that it's pretty much
hopeless that we'll agree on any particular approach -- including
what started this thread. Nor do I think we ought to since it's an
inherently driven by heuristics which involve risk/reward tradeoffs
for the receiver which a standard should not be trying to second
guess. Leaving some raw tools around like z= and letting receivers
decide for themselves is about all we need for now, IMO.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 28 Dec 2006 10:27:13 -0800

On Dec 28, 2006, at 6:19 AM, Michael Thomas wrote:

> never do this under any conditions which ventures into silly  
> net.cop delusions of what the protocol document can mandate, and a  
> more innocent caution that the actual headers to be used for a dkim  

Header copies might become useful as an interim fix when resolving  
issues created by "fix-ups" added by MDAs, which can be problematic  
at this time.  A hash value for the header would allow a faster  
isolation of problematic headers.   These issues should be resolved  
when the "fix-ups" are discontinued, but that might be holding one's  
breath for a while.

A more significant concern is related to the number of attempts  
needed to resolve which signature goes with which email-address,  
resulting from a missing link.  Don't assume the signing-domain and  
the email-address domain owners have exchanged private-keys or  
delegated domains in some manner.  That assumption represents a  
substantial barrier for deployment.

DKIM differentiated itself from S/MIME and OpenPGP by ensuring the  
signature remained _invisible_.  Expecting recipients to recognize a  
DKIM signing-domain assumes:

1) The signing-domain is somehow visible, which will likely confuse  
more than enlighten.

2) The signing-domain and the email-address are directly related,  
which is unrealistic in the general case.

Providing a means to link the email-address to the signature  
dramatically reduces the overhead associated with searching for a  
corresponding signature, assuming there are other means developed  
that indicates an association that does not depend upon the exchange  
of private-keys or zone delegations.

This linkage can be accomplished by making a rather minor change to  
the 'd=' and 'i=' syntax within the base draft.

3.5 The DKIM-Signature header field (i=)

---'d='

Was:

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  
(Signing by Parent Domains). When presented with a signature that  
does not meet these requirement, verifiers MUST consider the  
signature invalid.

Change to:

This domain MUST 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  
(Signing by Parent Domains) for key record extensions ('g=' and 't=s'  
to be valid).  When presented with a signature not meeting these  
requirements, other unspecified means to associate the email-address  
domain with that of the signing domain are required, otherwise  
verifiers MUST consider the signature invalid.

---'i='

Was:

Identity of the user or agent (e.g., a mailing list manager) on  
behalf of which this message is signed (dkim-quoted-printable;  
OPTIONAL, default is an empty local-part followed by an "@" followed  
by the domain from the "d=" tag). The syntax is a standard email  
address where the local-part MAY be omitted. The domain part of the  
address MUST be the same as or a subdomain of the value of the "d=" tag.

Change to:

Identity of the user or agent (e.g., a mailing list manager) on  
behalf of which this message is signed (dkim-quoted-printable;  
OPTIONAL, default is an empty local-part followed by an "@" followed  
by the domain from the "d=" tag).  The syntax is a standard email  
address where the local-part MAY be omitted. The domain part of the  
address is not required to be same as or a subdomain of the value of  
the "d=" tag.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 28 Dec 2006 18:06:13 -0600

>subject) that works, and use that, not considering the other.

This seems quite simple to me.  If the domain owner doesn't care about 
protecting headers, they should not sign them.  If they care about 
protecting headers from being modified, they should sign them.  

The presence of a failed signature shouldn't affect processing.  Treating a 
failed signature as anything other than no sognature seems a poor practice 
to me.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Thu, 28 Dec 2006 18:18:22 -0800

On Dec 28, 2006, at 4:06 PM, Scott Kitterman wrote:

> This seems quite simple to me.  If the domain owner doesn't care  
> about protecting headers, they should not sign them.  If they care  
> about protecting headers from being modified, they should sign them.
>
> The presence of a failed signature shouldn't affect processing.   
> Treating a failed signature as anything other than no signature  
> seems a poor practice to me.

The concern is not about meeting a signer's expectation.  The current  
base draft stipulates known bad signatures should not be removed when  
signing a message. A recipient should expect a need to avoid dead  
signatures.  It might also become common for a signer not to be  
"linked" to some header via an arrangement between a contained email- 
address domain and the signing domain.  Such arrangements involve  
sharing private-keys or zone delegation.  Such arrangements are  
likely expensive and may require mutual coordination between as many  
as three entities.

Association by reference is an alternative that can be done  
autonomously.  This alternative provides the email-address domain  
owner greater freedom that also does not require that their providers  
hold either their private keys or control a portion of their domain.   
What happens when a signature's linkage to an email-address  
meaningful to the recipient is not directly asserted due to a  
limitation of the signature's syntax?  A much higher network overhead  
is the result, that might be exploited.

A lack of linkages may occur when DKIM is for abuse reporting aiding  
in the defense of outbound IP address space.  Expense and support  
issues associated with adding originating headers to someone's  
message may cause a mode of operation devoid of common-domain  
linkages, despite expectations declared in the base draft.  When  
there is only one email-address the recipient wishes to verify, there  
should never be a need to validate more than one signature.  By  
extending the syntax of the 'i=' parameter, the signer makes the  
linkage explicit, even when domain zones or private keys have not  
been shared.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 30 Dec 2006 12:43:10 -0000

>> subject) that works, and use that, not considering the other.

ISTM that this sort of requirement can only arise where the original  
signer has some expectation that some header WILL get altered during  
transit, and wants to cover both possibilities.

> the base spec which should, IMO, just define the mechanics of the  

And that was my reaction when I read this suggestion. Anything that can be  
done with two signatures can probably be done as well with imaginative use  
of 'z='.

The only snag is that the draft says, of the 'z=':

Verifiers MUST NOT use the header field names or copied values for  
chacking signatures in any way. ...

Whyever not? If the verifier can get soe useful infornmation out of the  
'z=' (such as by restoring the 'z=' version of the header and seeing  
whether that mends the broken signature, then why forbid it? Just what the  
verifier might deduce from that situation I am not sure, but that is the  
verifier's problem, not ours.

Here is another example where the 'z=' might actually be useful.

Under EAI, there is a header
    Header-Type: UTF8
During transit, the headers may get downgraded, thus breaking all sorts of  
signatures. But, at the same time, that header gets changed to
    Header-Type: downgraded
So if the original signature recorded 'z=Header-Type: UTF8' (OK, that SP  
should have been dkim-quoted, but you know what I mean) then the verifier  
at least knows what has happened and do somethig intelligent (even if only  
to say, "sorry, this message has been UTF8 downgraded - you will have to  
resolves your suspicions yourself" - or else it might try to upgrade the  
message and then try the signature again). All seemingly reasonable,  
except that dkim-base syas it MUST NOT do such sensible things. Why not?

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