Subject: Re: [ietf-dkim] Proposal for specifying syntax and semantics for multiple signatures

From: Paul Hoffman <[email-masked]>
Date: Sat, 1 Apr 2006 09:04:29 -0800

At 4:54 PM -0800 3/30/06, Jim Fenton wrote:
>I'm concerned that including verification results is going to introduce
>a whole bunch of new semantics (and possibly transitive trust) to the
>multiple-signature case.

I am hearing a whole bunch of push-back and no support for the 
verification passthrough. Unless support appears in the next few 
days, I'll revise the proposal to remove it. I'll also change the 
"simple canonicalization" as well.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Sat, 01 Apr 2006 12:34:32 -0800

> "simple canonicalization" as well.

There is an alternative option that flags signature roles
(primary/secondary, MSA, Mediator, and MDA with the w= option). This
would allow an MDA or Mediator to sign a verification header field and
not be confused with the signature added at the message's point of
origin, when from the same domain.  For example, a list-server could use
an instance of an MSA that adds signatures in the role of Mediator. 

Just a single signature for each role is permitted.  This restriction
limits the extent of any amplification created evaluating signatures.
Prior MSA and MDA signatures would be removed by the MSA.  Except by an
MSA, the MSA signature would never be over-written.  The Mediator would
represent the only instance where a sequence of signature replacements
may occur.  The simplest approach would be to delete prior signatures of
the Mediator role.

The dkim-option draft suggests rather than removing prior signatures,
the b= value is overwritten with verification results.  The stepped-on
signatures could indicate which role, instance, sequence and whether the
stepped-on signature had verified.

The stepped-on signatures becomes: 

"b=!<role>.<instance>.<sequence>.<verification>"

The highest instance of the stepped-on signature could be included
within the signed hash for that role (both primary and secondary)
according to the sequence.

-Doug

---

From: <[email-masked]>
Date: Sat, 1 Apr 2006 17:16:17 -0500

Many folks use edge devices that look/act like an mta but is antispam/av oriented. Dropping a dkim plugin should be no more dificult that deploying a new av engine.
thanx,
bll

-----Original Message-----
From: [email-masked] on behalf of Michael Thomas
Sent: Fri 3/31/2006 6:32 PM
To: Mark Delany
Cc: [email-masked]
Subject: Re: [ietf-dkim] Proposal for specifying syntax and semantics formultiple signatures
 
Mark Delany wrote:

>On Fri, Mar 31, 2006 at 02:25:49PM -0800, [email-masked] allegedly wrote:
>
>  
>
>>And let's please not forget that even if this got fixed tomorrow the amount of
>>time it takes to significantly deploy new MTA versions is very long - far
>>longer than we can afford to wait.
>>    
>>
>
>I'm confused. We expect wide-spread use of this protocol without
>deploying new MTAs? That's quite the feat.
>  
>
With milter, you don't have to upgrade your sendmail version. For us,
we'd probably have to go through a lot more contortions to get our
infosec folks to buy into a new sendmail version for our production
environment. Not undoable, but definitely harder.

My understanding is that other MTA's have similar plugin kinds of
capabilities too.

       Mike

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 1 Apr 2006 19:07:59 -0500

From: "Paul Hoffman" <[email-masked]>

>> I'm concerned that including verification results is going to
>> introduce a whole bunch of new semantics (and possibly transitive
>> trust) to the multiple-signature case.

> "simple canonicalization" as well.

I'm sure I'm not telling anything you don't know, but it seems to me this is
not a weekend crowd. Most input seems to be only during the weekdays.  So
your deadline should be atleast Tuesday or Wednesday. :-)

Anyway here is my input:

In all honesty, I had a relatively hard time understanding the main issue
and proposal you made when I think that there needs to be more system
engineering here in regards to considering how SSP can help the process.

I think the overall goal is to "maintain integrity of mail distribution" in
the current mail infrastructure and to determine what are the minimum change
requirements in order to make DKIM work.

In other words, SSP helps define what your proposal should state.

Examples:

o Exclusive Signing Policy (SSP draft, o=!)
o No Mail Expected Policy (SSP draft, o=.)
o Weak Signing Policy (new proposed SSP, o=?)
o No Signing Policy (No SSP record - conflicts with BASE-00)

To maintain integrity, these will dictate how additional handling and
distribution of the mail *SHOULD* be done.

A complaint middleware, regardless of type and purpose, MUST NOT:

    - RESIGN, nor
    - ADD, nor
    - STRIP

without violating the integrity and consistency of the protocol methodology.

If this is to be allowed, then the SSP for the domain must change to
something less restrictive such as the next domain SSP declarations.

o Neutral Signing Policy (SSP draft, o=~)
o Strong Signing Policy (SSP draft, o=-)

These two policies allow for additional signatures to be present. So once
again, in order to maintain the integrity and survival of transports, the
middleware must adhere to the domain signing policy.

In this case, for NEUTRAL, which says no signature is required, a middle
ware now has the design options to offer:

    - Skip adding signature (passthru)
    - Optional, add 3rd party signature (3PS).
         - If adding, optional to remove original

However for the STRONG policy, the designs options are now:

    - Skip adding signature (passthru)
    - If Body Content will change, Add 3PS.

Much will depend if the middle ware is going to break the body content.

NOTES:

1) The current specs defines EXCLUSIVE in a manner that suggest
   additional signatures are allowed but must be ignored. I have
   a conflict with this policy semantic.

2) WEAK was proposed by Arvel.

3) No (NONE) policy conflicts with BASE-00 "standalone usage"
   since having no SSP record fallbacks to a "NEUTRAL" policy.
   It is highly probably that many domains will use DKIM with the
   help of SSP to declare domains that have no association with
   mail or no have no expectation of signatures. In short, we
   need a SSP o= tag value that says "NO SIGNATURE EXPECTED" for
   this domain.

Anyway, to me, I find it very difficult to discuss protocol semantics in a
non-SSP environment.  It makes everything extremely more difficult, more
chaotic, more ambiguities, too many implementation issues.  If middleware
authors or resigners are going to have to change code to support your
proposal, I find it difficult as to why not also add SSP logic to help the
process for the middleware.  The last thing middleware authors want to do is
bring the integrity of DKIM mail.  If its made too difficult, then they may
opt to ignore DKIM, putt on the idea of dealing with adding new signatures,
and if they break the integrity, the blame is no longer on the middleware
but on the domain owner for allowing risky mail to be put thru their system.

That's my input on this.

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

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 1 Apr 2006 19:50:52 -0500

Clarification on the STRONG policy:

> These two policies allow for additional signatures to be present.
> So once again, in order to maintain the integrity and survival of
> transports, the middleware must adhere to the domain signing policy.
>
> In this case, for NEUTRAL, which says no signature is required,
> a middleware now has the design options to offer:
>

For the STRONG Policy....

However for the STRONG policy (Signature Required, 3PS optional),
consistency is established when the middleware designs options are now:

    - No Content Change Expected

         - Skip adding signature
         - Optionally Add 3PS

    - Content Change Expected - PROTOCOL VIOLATION SEE BELOW

         - (Optionally?) Remove Original
         - Must Add 3PS

The protocol violation begins when a policy requires an OA signature. So if
the content is broken, this will break the verification.

This is where SSP can be adjusted with additional policies, policy
attributes or provisions that offer guidance in the area of removing
signatures.

Also note the following real possibility:

A list manager is adamant about adding footers, even possibly change in
subject lines with list forum tags.  No one or software is going to dictate
this local list requirement.  However, he may desire to be support of DKIM
as well where it is possible.

This means that the LIST Server developers may offer design options to
control the subscription process to make the whole process easier.

For example:

   --- New DKIM List Server Options ---

    [X] Reject Subscription from Domain with the following
        Sender Signing Policies (SSP):

        [X] EXCLUSIVE
        [X] WEAK
        [X] NEVER (NO MAIL EXPECTED)
        [X] NO SIGNING (No current SSP available)
        [_] NEUTRAL
        [X} STRONG
        [X] USER

There is nothing in the world that prevents this from happening if its going
to make the whole DKIM issue easier to a) adopt, b) program and c) remove
liability and support responsibilities of the list owners.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 02 Apr 2006 02:51:44 +0100

Folks,

There have been a few proposals in this thread and
also a number of comments/objections/noteworthy
things. But not, so far, much approaching a
conclusion.

So, in an attempt to move towards that,  let me
try to ask for opinions on this discrete part of
the issue: When an n-th signature(*) is added by
some signer, does that mean:

a) I take independent responsibility for having
    sent/fowarded (the bits of) this email (that I've
    signed), or,
b) Me too, whatever that previous good signer
    meant - it's not gotten worse.

I think I'd personally design different mechanisms
for each, but then maybe that's just me. Anyway,
which signer perception ought we be trying to
represent, and does the verifier care in any case?

Stephen.

(*) Ignoring >1 signature from the same signer, e.g.
for algorithm agility purposes. Ignore possibly bad
signatures too for the moment if you don't mind.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 01 Apr 2006 18:33:33 -0800

Stephen,

>    meant - it's not gotten worse.

The meaning of a DKIM signature has been kept intentionally minimal and vague. 
Something like alternative (b) moves towards complex relationships among 
signers, whereas (a) retains basic simplicity.

So, I hope (a) is the choice.

To the extent that a signer includes the DKIM-signature header of a previous 
signature, that ought to mean nothing more than ordering, not semantics.

d/

-- 

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

---

From: Mark Delany <[email-masked]>
Date: Sun, 2 Apr 2006 02:51:04 +0000

> Many folks use edge devices that look/act like an mta but is antispam/av oriented. Dropping a dkim plugin should be no more dificult that deploying a new av engine.

Are you talking about signing or verifying or both? Have you actually
done this or are you speculating about the ease? Are you considering
key management and DNS rollout in your claim about "no more
difficulty" or are you ignoring that aspect? Have you considered any
need to authenticate submitters or is that irrelevant?

If folk here are thinking that DKIM is a mere matter of adding a
plugin to existing infrastructure they are sadly mistaken. And to
justify protocol designs on that assumption are also mis-guided and
narrow-minded.

The people I've been been working with have actually been deploying
this stuff on a large scale with a large number of participants for a
number of years. They have *all* had to deploy new s/w and new
processes to participate. No exceptions.

That this group contains a number of folks who are capable of running
their tiny infrastructure as a DKIM experiment does not constitute the
Internet reality. As a group we should be very wary of their
disproportionate influence simply because such folk are present and
vocal on this list.

The almost religious approach to "must be milter compatible" is a case
in point. Such constraints are largely irrelevant to the major senders
and the major receivers I've been dealing with - yet already such
constraints seem to pervade the discussion here simply because three
or four vocal participants happen to use a milter as a convenient
implementation frame-work.

Mark.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 01 Apr 2006 20:37:57 -0800

Dave Crocker <[email-masked]> writes:

> The meaning of a DKIM signature has been kept intentionally minimal
> and vague. Something like alternative (b) moves towards complex
> relationships among signers, whereas (a) retains basic simplicity.
>
> To the extent that a signer includes the DKIM-signature header of a
> previous signature, that ought to mean nothing more than ordering, not
> semantics.

I have to agree with Dave here. (b) sounds way too confusing.

-Ekr

---

From: Barry Leiba <[email-masked]>
Date: Sun, 02 Apr 2006 00:33:11 -0500

> the issue

And I'd like to get us to close on two other discrete parts:
1. Whether we want to have a mechanism to let the signature survive the 
reordering of multiple sig headers or not.  I've heard Mike and Dave say 
no, we don't.  Is that correct?

2. Whether we want to be able to detect the removal of a signature 
header (as perhaps in the case of a "stronger" one and leaving a 
"weaker" one).  I think the consensus is that we don't care about this; 
I'd like to confirm that.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([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: Dave Crocker <[email-masked]>
Date: Sat, 01 Apr 2006 21:56:35 -0800

Barry Leiba wrote:
> reordering of multiple sig headers or not.  
...
> header (as perhaps in the case of a "stronger" one and leaving a 

My question for each is why?

To do either of these requires additional mechanism.

So the question is what benefit will accrue... and why that benefit is essential 
to a task of the type DKIM is intended to perform?

d/

-- 

Dave Crocker

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 2 Apr 2006 04:34:02 -0400

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>

> represent, and does the verifier care in any case?

I think it depends on your "Verifier" the guys who have to make the decision
with all the junk coming into the system how it will view it.

Sorry if I confuse the issue, but I just don't get it.

Are we suppose to turn a blind eye to the quality of the message and just
look at who is responsible?  If so, then who cares what the message quality
is as long as it comes from a "good person."

I just don't understand how to read your limited options.  But if I try to
understand, I think, the answer is B because Eric Allman's DKIM verification
algorithm is to declare the message DKIM verified (VALID) if atleast 1
signature is valid. If so, therefore the answer is closer to B.

If the answer is A like Dave believe it should be, yet no semantics and
rules applies, then how can you assign responsibility?  You need some kind
of interpretation if you wish to assign responsibility.

---

From: Douglas Otis <[email-masked]>
Date: Sun, 02 Apr 2006 04:43:46 -0700

On Sat, 2006-04-01 at 21:56 -0800, Dave Crocker wrote:
> > 1. Whether we want to have a mechanism to let the signature survive
> > the reordering of multiple sig headers or not.  
> ...

Yes for 2. Perhaps a simple mechanism added optionally.

> So the question is what benefit will accrue... and why that benefit
> is essential to a task of the type DKIM is intended to perform?

Transitioning algorithms in signed email may take long periods of time.
When there are exploits possible with a prior algorithm being phased-
out, until it is possible to ensure acceptance with just the newer
convention, including both conventions will be required.  This period
could span a significant amount of time, and depend upon the motivation
of all verifiers. 

Not have a mechanism to detect when the stronger signature is missing
means even when the verifier does support a newer convention, the
exploit remains possible, even for those verifiers that care about the
problem.  Selectively sending or verifying adds a greater amount of
overhead.

A simplest scheme would be to mark keys and signatures either primary or
secondary and delete prior signatures.  For signatures to be retained
with common domains at the MSA, Mediator, or MDA, these roles could be
combined with the primary/secondary indication.  This differentiation of
sources for signatures should safely allow these roles to establish a
set of signatures that can be retained without domain conflicts.

The greatest difficulty would be establishing an MSA instance that signs
in the role of the Mediator, for use with list-server applications, as
example.  Everything else would be statically defined.  Rules for
handling signatures could default existing headers to be MSA-Primary
without causing a problem.  When the role is added to the signature/key,
it would be the same for all messages and require just a small amount of
fixed text.

There is another benefit signature roles provide. This benefit is found
when a local trust database are being maintained.  These signature roles
could minimize user interaction and improve security.  This interaction
might occur when a conflict otherwise appears to exist.  These trust
databases would be used for message annotation.  A message with a
signature with a non-matching role could be silently ignored, as it
would not receive the annotation.  This annotation might be which folder
the message is placed into, for example. 

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Sun, 02 Apr 2006 06:40:52 -0700

> no, we don't.  Is that correct?

The current mechanism of dkim-sig survives reordering just fine.
My opinion is to not break what isn't broken.

> I'd like to confirm that.

I don't care about this.

		Mike

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 02 Apr 2006 05:45:22 -0700

> problem.  Selectively sending or verifying adds a greater amount of

Can you explain what "the exploit" means in this context?
I understand that technically you're talking about stripping out
the stronger signature, but under what set of circumstances do you
believe that this is useful as an attack?

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Sun, 02 Apr 2006 06:46:40 -0700

> I have to agree with Dave here. (b) sounds way too confusing.

Mein Gott. And it's not even 1-April.

+1

		Mike

---

From: Barry Leiba <[email-masked]>
Date: Sun, 02 Apr 2006 11:44:03 -0400

...
> is as long as it comes from a "good person."

We have to be clear about what DKIM is and isn't.

DKIM is something that lets a sender say "my domain sent this message".
DKIM is something that lets a verifier confirm that, and use it as part 
of its decision of what to do with the message.

DKIM is NOT something that says ANYthing about the trustworthiness of 
the signer, or of the "quality" of the message.

Any decisions about the quality of the message or the goodness of the 
source are made by the verifier, POSSIBLY using the information provided 
by DKIM as input, but not directly resulting from DKIM.

<chair>
In particular, any attempt to include that sort of information in DKIM 
is explicitly out of scope for this working group.
</chair>

Barry

---

From: Dave Crocker <[email-masked]>
Date: Sun, 02 Apr 2006 09:19:31 -0700

Barry, et al,

> We have to be clear about what DKIM is and isn't.

yes, indeed.

> DKIM is something that lets a sender say "my domain sent this message".

(no eye-rolling is allowed, here...)

When I harp about the problems of using the term "sender", for DKIM, it is for
exactly this type of discussion.

If you went out and asked 20 non-technical people -- enough to make an 
interesting sample of the population -- what they think your above sentence 
means, I predict that all 20 would respond that the semantics were along the 
lines of "someone in that domain wrote the message", rather than something like 
"something (person/software) related to that domain *handled* the message."

My own view is that getting the technology right is frankly the minor challenge, 
in getting widescale deployment and use of DKIM.  The major challenges are

    a) expectations for it, and
    b) ease of administration and use.

A misunderstanding of the actual meaning of a DKIM signature seems certain to 
defeat the first requirement. At the least, try thinking of how poor the new 
reporting on DKIM is likely to be when the reporter is subject to this 
misunderstanding.

Even within the DKIM technical community, there seems to be a pretty wide range 
of beliefs about the meaning of a DKIM signature.  I suspect this very thread 
exemplifies it.

> is explicitly out of scope for this working group.

Given the predisposition folks have towards such misunderstandings, it well 
might be worth a distinct section of text (with a table of contents entry) that 
anticipates the problem and discusses it.

d/

-- 

Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Sun, 2 Apr 2006 09:49:36 -0700

> DKIM is something that lets a sender say "my domain sent this  

Not even that, as I understand it. In some cases the domain that's  
signing the
message will have nothing at all to do with putting it on the wire,  
and in some
cases nothing to do with the details of composing the message. (Back  
to Daves
distaste for the word "sender").

"Someone who has access to a private key associated with this domain  
(probably
someone authorized by someone associated with the DNS setup for this  
domain)
has signed the content of this message, and the message hasn't  
changed significantly
since they did that." is a bit closer.

That doesn't make for much of an elevator pitch, though, so perhaps  
'A DKIM signature
from paypal.com says "I am paypal.com, and I authorize this message!"'.

Cheers,
   Steve

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 2 Apr 2006 13:03:49 -0400

----- Original Message -----
From: "Barry Leiba" <[email-masked]>

> by DKIM as input, but not directly resulting from DKIM.

So you are creating a functionl specification and mandate, to mold local
policy on how to NOT handle the new found unchecked DKIM junk?   You got to
be kidding that you will control this market.

> is explicitly out of scope for this working group.

I thought we have moved on to SSP?  SSP is not out of scope. Correct? I am
referring to SSP to help answer many of these questions being raised,
including this thread about nth signatures and ambiguious mandate on how it
should be "Intepreted!"

It is a moot point what a nth signature means if a nth signer was not
authorized by the domain owner to resign it.  For some reason, that isn't an
important consideration.

This DKIM-only simplicity is an extremely harmful mandate to impose on
verifiers, specifically vendors who such as us who need to implement this
stuff and convince customers this stuff has any value or payoff.

I am not just making this up, you know?  I am not trying to be ANTI-DKIM,
you know?  I want it to work too.

My concern is that we will have a growth DKIM-only systems out there
creating a deluge of high volume invalid, fraudulent DKIM messages with no
controls in place and because of this weak and neglectful half-baked
incremental design approach, we will have two markets to deal with:

    - the DKIM-only market with tons of fraud
    - DKIM market with some unknown augmented technology only privy to
      a few here that isn't here yet.

You guys are mandating a technology that is quite frankly, infested with
flaws. You want to tell us what it means, with what seems to me a careless
attitude or lack of a clear vision (intentionally made vague I suppose) for:

    - determining how to clearly implement it,
    - what scalability issues will come from it,
    - and completely ignore the all error and worst case scenarios.

Where is the error analysis in all this? None!

Where is the system engineering in all this?  None!

Sorry, I don't have any misunderstanding of what you or Dave expect DKIM to
be.  I understand very clearly what "yall" trying to do.  But it is flawed
and dangerous and you have no evidence nor shown any proof to the contrary
to suggest a DKIM-ONLY implementation is going to be safe in a widely
adopted network.  I see no consideration in handling predictable scenarios
of being bombarded with DKIM signed mail - good or bad.

I put together some diagrams of a highly efficient DKIM/SSP verifier system
that protects the DKIM DOMAIN owner from exploited usage of domains.  It is
based around SSP - a simple consideration that resolves many of the current
signing questions.

See

http://www.winserver.com/public/ssp/ssp.htm

Hopefully this will make some sense.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 02 Apr 2006 20:17:37 -0400

> including this thread about nth signatures and ambiguious mandate on how it

Well, first, we're still focusing on the base, which is supposed to be 
done within two months now.

Second, even SSP does not aim to address the quality of the message or 
the trustworthiness of the signer.  The closest it comes to that is that 
in the current formulation, the RFC822 From domain can advise the 
recipient that it would like them to be suspicious of messages that are 
not signed directly by it.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Sun, 02 Apr 2006 20:21:27 -0400

> interesting sample of the population -- what they think your above 
> sentence means, I predict that all 20 would respond that the semantics 
> were along the lines of "someone in that domain wrote the message"

Yes; I was trying to be very terse, and obviously succeeded too well. 
The wording I usually use is "my domain put this message onto the 
Internet", usually clarifying that it could be an initial "put" or a relay.

> rather than something like "something (person/software) related to that 
> domain *handled* the message."

I like "handled".  Of course, I'm sure we'd get 20 different versions of 
what THAT means too, so....

> Given the predisposition folks have towards such misunderstandings, it 
> well might be worth a distinct section of text (with a table of contents 
> entry) that anticipates the problem and discusses it.

...that's probably worth doing, yes.
Thanks, Dave, for volunteering to write the text.  Post here and send to 
Eric when it's ready.

Barry

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 2 Apr 2006 21:51:52 -0400

----- Original Message -----

> done within two months now.

And you think there is nothing to be learned from SSP or not engineering
feedback that can help better mold the final base product?

> the trustworthiness of the signer.

Well, first, It might have been more appropriate to say Quality of the
Transaction instead.

Second, there are many levels of trust.  They one I believe you are
referring to is the Accreditation/Reputation concept.

But the other form of trust is established in the system's protocol
consistency.  It is a deterministic concept. Not heuristic.  That is what
SSP offers. It helps police the transaction.  It helps keep that "quality"
consistent. It helps promote transaction survival.  It helps make systems
work together better, and surely much better than a DKIM-only concept where
you currently have all this ambiquious questions and debates.

Have you found the time to understand the easy to follow DKIM/SSP logic
illustrated in:

> The closest it comes to that is that

You see, you say "advise."  I say "mandate, expose, dictate, define,
establish" a level of expectation in the formulation of the transaction.
That is not to suggest that the verifier will actually follow it, but that
it is a strong "standard" or BCP on expected behavior.  That is the basis
and framework of telecommunications. If protocol is not follow, then you
have failures and if you don't address these failures, then you will have
exploitations and all kinds of chaotic situations yet to be fully realized
but quite of bit of predictable chaos. I will venture to say if unchecked
failure outweight the good, than DKIM has failed in its purpose.

Fuzzy concepts that include semantics like "advise" is only appriopriate
where there is a no necessity to apply any other controls.  This is clearly
not one of them.  It is akin to the same issues that begat EHLO and MAIL
FROM.  No mandate to follow protocol consistency and we ended up with a
multi-billion industry wide costly suite of email security issues.  We are
repeating history with this unchecked DKIM-only concept.

So what are really talking about here? The unsureness of middle ware, of
what could happen between two endpoints?

This begs the question, is DKIM appropriate for Mailing List systems?  It is
clearly not today.  Yet, one school is attempt to mold and detect "design
changes" to follow your "definitions."   Well, I as a seasoned engineer and
author too of SMTP and List Server software and I don't see any common sense
in the current suggestions.  I see more harm than good.  I am wrong, please
sure how DKIM is safe without SSP.  Please sure how you can in a much
clearer and clean matter resolve all these questions without SSP.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 03 Apr 2006 00:37:27 -0700

Hmmm...

>> well might be worth a distinct section of text (with a table of 
>> contents entry) that anticipates the problem and discusses it.
> 

we should probably take this act on the road.  i almost heard the ba-dump bump 
from the drums.

  - - - -

The overview is going to have this sort of text, though it would not hurt to 
have it repeated, since it is non-normative.

So, how about some subset of:

     DKIM lets an organization take responsibility for a message.  That 
organization is a handler of the message, either its originator or an 
intermediary in the transport sequence.  The owner of the domain name being used 
for a DKIM signature is declaring that they are accountable for the message. 
This means that their reputation is at stake. That is, their reputation is the 
basis for evaluating whether to trust the message for delivery.

     The responsible organization adds a digital signature to the message, 
associating it with a domain name of that organization.  Typically, signing will 
be done by a service agent within the authority of the message originator's 
Administrative Management Domain (ADMD). Signing might be performed by any of 
the functional components, in that environment, including: Mail User Agent 
(MUA), or Mail Submission Agent (MSA), Internet Boundary MTA. DKIM permits 
signing to be performed by authorized third-parties.

     After a message has been signed, any agent in the message transit path can 
choose to validate the signature. Typically, validation will be done by an agent 
in the ADMD of the message recipient. Again, this may be done by any functional 
component within that environment. Notably this means that the signature can be 
used by the recipient ADMD's filtering software, rather than requiring the 
recipient end-user to make an assessment.

     Receivers who successfully validate a signature can use information about 
the signer as part of a program to limit spam, spoofing, phishing, or other 
undesirable behavior, although the DKIM specification itself does not prescribe 
any specific actions by the recipient.

     Whether a DKIM signature improves deliverability or bypasses filters is 
entirely at the discretion of the validating receivers. When a message has been 
signed using DKIM, a receiver uses their knowledge about the signer to determine 
the most appropriate treatment of the message. It is expected that messages from 
a signer who has a good reputation will be subject to less scrutiny by the 
receiver's filters.

     Examples of what DKIM does not, by itself, do include:

         * DKIM does not offer any assertions about the behaviors of the 
identity doing the signing.

         * DKIM does not prescribe any specific actions for receivers to take 
upon successful (or unsuccessful) signature validation.

         * DKIM does not provide protection after message delivery.

         * DKIM does not protect against re-sending (replay of) a message that 
already has a valid signature; therefore a transit intermediary or a recipient 
can re-post the message in such a way that the signature would remain valid, 
although the new recipient(s) would not have been specified by the originator.

d/
-- 

Dave Crocker

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 3 Apr 2006 05:49:47 -0400

Dave,

All would like to see is a robust design against failure.

You are not offering this and this sincerely concerns me as I think this
puts the new domain responsibility and reputation at risk and the verifier
will sense the biggest burdens.

I am not talking about "spam filtering" "content analysis" but simply
protocol consistency.

You are asking domains to take responsibility and that its now their
reputation at stake. Yet you are not offering domains any assurance that it
will be safe, nor that it will reliable work or how verifiers should handle
the conflicts and failures.

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: "Barry Leiba" <[email-masked]>
Cc: "Eric Allman" <[email-masked]>; <[email-masked]>
Sent: Monday, April 03, 2006 3:37 AM
Subject: Re: [ietf-dkim] Proposal for specifying syntax andsemantics
formultiple signatures

---

From: Arvel Hathcock <[email-masked]>
Date: Mon, 03 Apr 2006 11:46:36 -0500

> When an n-th signature(*) is added by

Stephen, it means (a)

-- 
Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Mon, 03 Apr 2006 11:53:04 -0500

> the reordering of multiple sig headers or not.  I've heard Mike and
 > Dave say no, we don't.  Is that correct?

I've also said it's added complexity that I don't think we need.

 > "weaker" one).  I think the consensus is that we don't care about
 > this; I'd like to confirm that.

Right, we don't care about that.

-- 
Arvel

---

From: Douglas Otis <[email-masked]>
Date: Mon, 3 Apr 2006 12:04:01 -0700

> Right, we don't care about that.

Email can not easily negotiate these algorithms.  Are you expecting  
to sign messages differently for each recipient?

A verifier must be able to detect when a stronger signature has been  
removed when two signatures are offered.  Without this ability to  
detect such a removal, all verifiers and senders will remain at risk  
to a downgrade attack during perhaps a _very_ long algorithm  
transition period.  It requires very little to repair this problem at  
the outset.

-Doug

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 03 Apr 2006 13:14:27 -0700

> transition period.  It requires very little to repair this problem at

Sorry, I still don't understand what the purpose or impact of this
attack is. Can you explain?

-Ekr

---

From: Douglas Otis <[email-masked]>
Date: Mon, 3 Apr 2006 14:54:50 -0700

On Apr 3, 2006, at 1:14 PM, Eric Rescorla wrote:

>> Email can not easily negotiate these algorithms.  Are you  
>> expecting to sign messages differently for each recipient?
>>
>> A verifier must be able to detect when a stronger signature has  
>> been removed when two signatures are offered.  Without this  
>> ability to detect such a removal, all verifiers and senders will  
>> remain at risk to a downgrade attack during perhaps a _very_ long  
>> algorithm transition period.  It requires very little to repair  
>> this problem at the outset.
>

An attack may be enabled by replaying a message compromised due to a  
weak hash, key, or canonicalization algorithm.

For example, a message is signed with two signatures by example.com.   
The secondary signature with the prior algorithm is added to the  
message to permit a transition to occur.  This change will take time,  
even after exploits have been noted.  To protect verifiers that have  
implemented the stronger algorithm and to accommodate verifiers still  
not upgraded, two or more signatures are added to the message.   
Assume a bad actor knows how to modify the content of a previously  
signed message by inducing the same hash.  This hash technique only  
works for the prior algorithm, so the bad actor excludes the  
resistant signature in their replayed compromised message.  DKIM does  
not encompass elements of the message envelope, only the message  
contained within the envelope.  This permits the bad actor a fair  
amount of freedom to exploit a compromised message.

During a transition phase, perhaps a primary and secondary signature  
are added to a message.  A means is needed to protect verifiers from  
a possible exploit that "downgrades" the selection of algorithms  
normally offered by the sender to only being that of the secondary  
signature with the depreciated algorithm.  Marking keys as primary  
and secondary permits detecting the removal of a stronger algorithm  
when only finding secondary signature/keys from the signing domain.

When the verifier discovers an unknown primary algorithm, the  
verifier should confirm the sender offers the algorithm in the  
primary key.  This would be done by establishing a consistent method  
to identify the algorithms in both the signature and key.  Normally  
this is done using a numbered index in an IANA table.  This is _not_  
a property of DKIM as it is currently defined.   Mark at least one of  
perhaps several signatures/keys added to the message as primary, and  
those signatures using soon depreciated algorithms as secondary.  Any  
verifier that implements the newer algorithm would therefore be  
protected from messages where bad actors have exploited a weakness  
found in the depreciated algorithm, even though both the sender and  
verifier supports the newer algorithm.  The verifier would prefer the  
primary key when supported by the verifier.  If the algorithm in not  
supported by the verifier, the verifier confirms the sender offers  
newer algorithm.  The verifier could then utilize the secondary  
signature and perhaps make some message annotation.  If only a  
secondary signature/key were discovered for the message, the message  
could be rejected.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Tue, 04 Apr 2006 08:44:31 -0700

> weak hash, key, or canonicalization algorithm.

You didn't answer his question (or, by derivation, mine.)

d/
-- 

Dave Crocker

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 Apr 2006 08:55:50 -0700

Revised to:

- remove verification passthrough
- change the canonicalization to what is being used anyway
- removed the ordering requirement
- softened the wording about bid-down attack

---------------------
Summary:
A sender signing a message that already has one or more DKIM-Signature
headers keeps the earlier headers and signs over them.

---------------------
Rationale:
Signers need a way to attach multiple signatures when transitioning from
one signature algorithm to another, when transitioning from one hash
algorithm to another, and even from one protocol version to another.
Further, there are many scenarios where a sender is forwarding a message
that is already signed,  and wants to add its own signature. This can
be done in a way to allow parallel signatures during transitions.

---------------------
Changes:

Add to section 3.5:

	p= Earlier signatures (plain-text; REQUIRED if there is already one
	or more DKIM-Signature headers in the message). This tag lists the
	hashes of the DKIM-Signature headers that exist before this
	DKIM-Signature header is added. The hash is computed using the hash
	algorithm that is used in the signing algorithm (taken from the "a="
	tag), using same header canonicalization on the DKIM-Signature
	headers as is being used already. The order of the hashes is not
         significant.

	sig-p-tag = %x70 [FWS] "=" [FWS] sig-p-tag-hash
	                   0*( *FWS ":" *FWS sig-p-tag-hash)

	sig-p-tag-hash = base64string

Change in the "h=" description of section 3.5:
OLD:
	The field MUST NOT include the DKIM-Signature header field that is
	being created or verified.
NEW:
	The field MUST NOT include any DKIM-Signature header field.

Change section 4 to read:

	4.  Semantics of Multiple Signatures

	A signer that is adding a signature to a message inherently signs
	all DKIM-Signature headers that exist in the message before the new
	signature using the "p=" tag. If a single signer adds multiple
	signatures, such as using different signing or hashing algorithms,
	each signature stands on its own, meaning each signature covers all
	of the previous signatures, even ones from the same signer.

	A signer applying multiple signatures with different signing
	algorithms SHOULD first sign with the signer's most-preferred
	algorithm, then with the next-most-preferred, and so on. This ordering
	prevents an attacker from removing more-preferred signatures from a
	message without the recipient being able to detect the removal. Note
         that the recipient MAY ignore such removal, such as if the recipient
         is satisfied with the strength of the remaining signature(s).

	Signers MUST NOT remove any DKIM-Signature headers from messages
	they are signing, even if they know that the headers cannot be
	verified. Doing so would break the chain of signatures.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Apr 2006 09:16:07 -0700

> - softened the wording about bid-down attack

It would be nice if you responded to my initial post on this subject.
But in particular:

 >     p= Earlier signatures (plain-text; REQUIRED

I have no idea why this merits even a SHOULD let alone a REQUIRED.
The rationale makes a pretty big leap from needing to have multiple
signatures to needing this new required functionality. As far as I
recall, nobody's answered why it's needed, let alone mandatory.

		Mike

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 04 Apr 2006 17:20:25 +0100

Paul,

A question about the semantics bit.

What do we need to say about what a verifier MUST, SHOULD
or MAY do/NOT do, if sig1 has "h=foo+bar" but sig2 has "h=bar"
(or whatever other variant you prefer)?

Perhaps the right answer is "nothing": those fields are
meant for the verifier to get the crypto right, they're
not for anything else. Should we say that if we believe
it?

However, I suspect that some verifiers will tell someone
about what "h=" was when they see a single signature, in
which case should we say that such verifiers SHOULD present
info about all sigs or something. If a verifier reports
partial or confusing information there, then trouble may
well ensue. OTOH, this is close to designing an API, and
that's not generally IETF business.

There'll be variations on this question for other tags
too, e.g. "z=", "i=" and maybe more.

Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 04 Apr 2006 17:27:34 +0100

Paul,

Another (littler) question, nearly a nit.

Currently "h=foo" is usable to say "I didn't sign foo cause it
wasn't there" (or some better wording), effectively meaning
that if someone adds a foo header field then the sig breaks.

Ought your proposal make reference to this, even if only
to include a reminder that making use of this feature/trick
is liable to be problematic if such a field is likely to be
added by a later MTA/signer?

Stephen.

PS: Out of interest - is anyone planning to use that trick?

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 Apr 2006 09:37:30 -0700

>I have no idea why this merits even a SHOULD let alone a REQUIRED.

For interoperability. The current document says that it does not say 
what multiple signatures mean, nor does it give a standard way for a 
signer to attach multiple signatures to a message.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 Apr 2006 09:39:02 -0700

>(or whatever other variant you prefer)?

My preference would be to say nothing. This is a recipient policy issue.

>that's not generally IETF business.

Exactly.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Apr 2006 10:00:09 -0700

> signer to attach multiple signatures to a message.

Do you consider this an adequate reply to all of the questions I asked?

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Tue, 4 Apr 2006 10:07:16 -0700

On Apr 4, 2006, at 8:44 AM, Dave Crocker wrote:
> Douglas Otis wrote:
>>> Sorry, I still don't understand what the purpose or impact of  
>>> this attack is. Can you explain?
>>
>> An attack may be enabled by replaying a message compromised due to  
>> a weak hash, key, or canonicalization algorithm.
>
>

DKIM can establish a trust relationship between the signing-domain  
and the recipient.  Being able to exploit that trust relationship can  
be used to both defraud the recipient, and damage the trust that  
might have been established by the signing-domain.  If there is an  
exploit that becomes a problem, both parties should be able to  
quickly upgrade and find protection.

The message may have been a message a financial institution asking to  
check the account and offering a helpful login link.  The recipient  
might trust this link when lead to understand this domain signs their  
messages and that their MDA/MUA places non-compliant messages into  
their spam folder.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 04 Apr 2006 18:08:11 +0100

> My preference would be to say nothing. This is a recipient policy issue.

Fair enough. Mine would just slightly be to point that out, e.g.
by saying that its a recipient policy issue.

If folks disagree saying so would be good.

>> that's not generally IETF business.

(You must be short of words today:-)

Are you agreeing with the first or last sentence there?

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 04 Apr 2006 18:14:40 +0100

Doug,

Douglas Otis wrote:
> DKIM can establish a trust relationship between the signing-domain and 
> the recipient.  Being able to exploit that trust relationship can be 
> used to both defraud the recipient, and damage the trust that might have 
> been established by the signing-domain.  If there is an exploit that 
> becomes a problem, both parties should be able to quickly upgrade and 
> find protection.
> 
> messages and that their MDA/MUA places non-compliant messages into their 
> spam folder.

Nor can I see what this has to do with removing one of a bunch of
signatures.

Maybe we should move on and you can raise the replay issue again
later (I bet you will, eh:-)

S.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 04 Apr 2006 10:19:03 -0700

Sorry, I think we're still talking past each other.

If we have two algorithms, Old and New, then there are three
kinds of signer and receiver, respectively: Old, New, and Both.
This gives us a 3-3 interop matrix, with four possibilities at
each cell:

NO      - receiver can't verify
Old     - receiver verifies with old algorithm
New     - receiver verifies with new algorithm
???     - see below

                               SIGNER
RECEIVER          Old          Both            New
Old               Old          Old             NO
Both              Old          ???             New      
New               NO           New             New

So, in the case of signers which only support the Old or New
algorithms, they will only sign with them and so there's no issue. The
attacker can of course remove either signature but that doesn't do any
good because it makes the message unverifiable. So, only the middle
column where the signer signs with both algorithms is interesting.

Similarly, if the receiver can only read either Old or New signatures,
then removing one of the signatures doesn't do any good--you can't
force him to do anything other than reject the message. So, this
leaves us with the only cell in this column being the one where
there is a switch-hitting signer and a switch-hitting receiver.
This only makes sense if (as you suggest) the attacker has some
way of modifying the message but retaining the validity of the
weaker signature.

The question then becomes whether this attack is important. As
I argued in the WG meeting, if a receiver is willing to accept
messages that are signed with only the Old algorithm (a necessary
condition for this attack) then they are also susceptible to
attack on messages from "Old" signers, of whom there will be
plenty. So, given that, I'm not sure that it's particularly
interesting to provide receivers who aren't interested in
defending themselves against that attack to protect them
specifically against downgrade.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 Apr 2006 10:36:30 -0700

>Are you agreeing with the first or last sentence there?

Sorry. I was agreeing with the last sentence.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 Apr 2006 10:35:23 -0700

>added by a later MTA/signer?

No, because it doesn't seem related to signing the DKIM-Signature 
header. There is no sensible way to use DKIM-Signature in h= to 
indicate "there will be no future DKIM-Signature headers".

Maybe I'm misunderstanding your question.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 04 Apr 2006 18:50:38 +0100

Paul Hoffman wrote:
> header. There is no sensible way to use DKIM-Signature in h= to indicate 
> "there will be no future DKIM-Signature headers".
> 

I think so.

Take some list related header field and two signers - the 1st signer
being the 1st outbound MTA and the 2nd signer being the list s/w (or
some other adjacent signer, whatever).

For some reason the originator doesn't want that list header field to
be signed, so he puts "h=<<list-field>>" even though there's on such
header on the message he signed.

Later the list adds a list-field header field and then adds its
signature (over whatever header fields, doesn't matter).

Now, as I understand it, its guaranteed that the 1st signature will
not verify. The second will, or won't, depending on the usual stuff.

My question was whether or not a reminder about this behaviour
would be useful.

S.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 Apr 2006 11:30:14 -0700

>My question was whether or not a reminder about this behaviour

It might be useful somewhere in the document, but not in the 
description of p=, given that we ust took out the "I did or did not 
verify the earlier signatures" stuff.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Tue, 04 Apr 2006 12:33:33 -0700

Eric, et al,

 > This gives us a 3-3 interop matrix, with four possibilities at

In the interest of exploring a simplification, let me re-raise a perspective 
that has been expressed by others:

It is important to be able to have multiple signatures, for transition issues, 
to make sure that the signer and validator share at least one, common 
algorithms.  That is the *only* concern about multiple signatures.

One can take the position that question of "strength" is almost completely 
irrelevant.

Here's why:

The validator either considers a signature "strong" enough or they don't.  That 
choice is the validator's and it does not matter in the least whether the signer 
agrees.

If someone does a downplay attack, the validator might be looking at a signature 
that is "weaker" but it won't matter.  Either the validator will consider it 
strong enough or they won't.

So, my question is:  what is wrong with this view of the issue?

Unless there is a compelling reason against this view, then it means that the 
most a DKIM specification needs to do is to include an observation like this, in 
order to a) acknowledge that there are downplay attacks, and b) demonstrate that 
they are not really relevant.

d/
-- 

Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Apr 2006 13:09:04 -0700

[transmogrified from Paul's original text]

     A signer that is adding a signature to a message merely creates
     a new DKIM-Signature header, using the usual semantics of the
     h= option. A signer MAY sign previously existing DKIM-Signature
     headers using the method described in section NN to sign trace
     headers. Signers should be cognizant that signing DKIM-Signature
     headers may result in signature failures with intermediaries that
     do not recognize that DKIM-Signature's are trace headers and
     unwittingly reorder them.

     When evaluating a message with multiple signatures, a receiver
     SHOULD evaluate signatures independently and on their own merits.
     For example, a receiver that by policy chooses not to accept
     signatures with deprecated crypto algorithms should consider such
     signatures invalid. As with messages with a single signature,
     receievers are at liberty to use the presence of valid signatures
     as an input to local policy; likewise, the interpretation of
     multiple valid signatures in combination is a local policy
     decision of the receiver.

     verified.

		Mike

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 Apr 2006 13:45:54 -0700

>     they are signing, even if they know that the headers cannot be

This works for me, as long as people are not worried about reordering 
of multiple DKIM-Signature headers in messages where the signer has 
included those headers in h=. If people are concerned about 
reordering of DKIM-Signature headers under a signature, then this 
change is insufficient on a technical level.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 04 Apr 2006 14:06:10 -0700

Dave Crocker <[email-masked]> writes:

> In the interest of exploring a simplification, let me re-raise a
> perspective that has been expressed by others:
>
> It is important to be able to have multiple signatures, for transition
> issues, to make sure that the signer and validator share at least one,
> common algorithms.  That is the *only* concern about multiple
> signatures.
>
> One can take the position that question of "strength" is almost
> completely irrelevant.
>
> Here's why:
>
> The validator either considers a signature "strong" enough or they
> don't.  That choice is the validator's and it does not matter in the
> least whether the signer agrees.
>
> If someone does a downplay attack, the validator might be looking at a
> signature that is "weaker" but it won't matter.  Either the validator
> will consider it strong enough or they won't.
>
>

In this context, I think nothing.

-Ekr

---

From: Dave Crocker <[email-masked]>
Date: Tue, 04 Apr 2006 14:25:04 -0700

Folks,

Eric and I agree.

This confirms the reports that have been coming in, recently.  Global climate 
change has actually resulted in ice-packs forming a solid layer, covering the 
nether regions of the after-world.

I hope the uniqueness of this event duly impresses others, since it could mean 
one-more "threat" -- downgrading --  that we don't have to worry about.

d/
-- 

Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 04 Apr 2006 22:59:23 +0100

>>     SHOULD evaluate signatures independently and on their own merits.

Is that really a SHOULD? How could it be tested? Perhaps "should"
is ok in this case.

>>     decision of the receiver.

That looks pretty good.	

>>     they are signing, even if they know that the headers cannot be

Is MUST NOT ok there, as opposed to SHOULD NOT? I seem to recall someone
wanting to be able to remove signatures to hide internal structure. Not
sure if that was on the list or not, and it does seem a little bit of a
corner case (one could in any case wriggle out of the problem by saying
it wasn't the signer that removed the sig, but it was some other bit of
code:-) No real opinion myself, just asking.

> This works for me, as long as people are not worried about reordering of 
> multiple DKIM-Signature headers in messages where the signer has 
> included those headers in h=. If people are concerned about reordering 
> of DKIM-Signature headers under a signature, then this change is 
> insufficient on a technical level.

If no-one wants to insist on signatures having to be sequential,
then this could be fairly easy!

S.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Apr 2006 15:10:43 -0700

> Is that really a SHOULD? How could it be tested? Perhaps "should"

I think you're right.

> code:-) No real opinion myself, just asking.

I copied this from Paul's original. I'm good either way, though
SHOULD seems more appropriate now.

		Mike

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 Apr 2006 15:14:05 -0700

>then this could be fairly easy!

Signatures have to be sequential if you sign them, given our current 
rules for signing and verifying h=. The question is whether or not we 
care about the cases where multiple signed headers get reordered, 
thus breaking the signature.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 Apr 2006 15:26:20 -0700

>SHOULD seems more appropriate now.

The MUST NOT was there in the earlier proposal because the 
association between p= and the headers was by hash values. This 
proposal removes that, and MUST NOT is not needed. If we use "SHOULD 
NOT", we need to say when it is OK to do it anyway. Proposal: "To 
avoid deleting information that might be valuable to the recipient, 
signers SHOULD NOT remove..."
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 04 Apr 2006 23:28:21 +0100

Paul Hoffman wrote:
> rules for signing and verifying h=. 

Then I'm confused. Someone want to help me out?

I was under the impression out latest proposal was that you didn't
have to, but could choose to, include (other) DKIM-Signature fields
in h= and that if you do so choose (i.e. you want sequential sigs)
that's fine, the verifier will do the right thing (if there's no
re-ordering), so inside h= DKIM-Signature is handled just like
Received. OTOH if you just want parallel sigs, you simply omit
DKIM-Signature from the h= and only bytes from this DKIM-Signature
will be input to hashing.

 > The question is whether or not we
> care about the cases where multiple signed headers get reordered, thus 
> breaking the signature.

Haven't heard much if any demand.

S.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Apr 2006 15:35:56 -0700

Paul Hoffman wrote:
> The MUST NOT was there in the earlier proposal because the association 
> between p= and the headers was by hash values. This proposal removes 
> that, and MUST NOT is not needed. If we use "SHOULD NOT", we need to say 
> when it is OK to do it anyway. Proposal: "To avoid deleting information 
> that might be valuable to the recipient, signers SHOULD NOT remove..."

Sounds good to me -- I was thinking of adding some text along the
"forensics" lines to reinforce that even bad signatures may be
useful to humans/stats collectors, etc.

		Mike

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 Apr 2006 16:02:31 -0700

At 11:28 PM +0100 4/4/06, Stephen Farrell wrote:
>>Signatures have to be sequential if you sign them, given our 
>>current rules for signing and verifying h=.
>
>Received.

Yup.

>OTOH if you just want parallel sigs, you simply omit

Some signers will want to sign parallel signatures for a variety of 
reasons, one of which is that they want to avoid the bid-down attack 
(despite the fact that we on this list agree it is not important). 
They do their first signature as normal, then they do their second 
signature, adding a "DKIM-Signature" to the h= list. This is 
optional, of course.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Dennis Dayman" <[email-masked]>
Date: Tue, 4 Apr 2006 20:37:20 -0500

I'm good with this.

-Dennis

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Michael Thomas
> Sent: Tuesday, April 04, 2006 3:09 PM
> To: Paul Hoffman
> Subject: [ietf-dkim] Alternative text for semantics of 
> multiple signatures
> 
> > Signers need a way to attach multiple signatures when transitioning 
> > from one signature algorithm to another, when transitioning 
> from one 
> > hash algorithm to another, and even from one protocol 
> version to another.
> > Further, there are many scenarios where a sender is forwarding a 
> > message that is already signed,  and wants to add its own 
> signature. 
> > This can be done in a way to allow parallel signatures 
> during transitions.
>

---

From: Douglas Otis <[email-masked]>
Date: Tue, 4 Apr 2006 18:58:36 -0700

On Apr 4, 2006, at 10:14 AM, Stephen Farrell wrote:
>>>> An attack may be enabled by replaying a message compromised due  
>>>> to a weak hash, key, or canonicalization algorithm.
>>>
>> and the recipient.  Being able to exploit that trust relationship  
>> can be used to both defraud the recipient, and damage the trust  
>> that might have been established by the signing-domain.  If there  
>> is an exploit that becomes a problem, both parties should be able  
>> to quickly upgrade and find protection.
>>
>> The message may have been a message a financial institution asking  
>> to check the account and offering a helpful login link.  The  
>> recipient might trust this link when lead to understand this  
>> domain signs their messages and that their MDA/MUA places non- 
>> compliant messages into their spam folder.
>

Conventional wisdom and practical experience suggests it is not  
readily practical to exploit the SHA-1 hash, at least not across  
major portions of a message.   Whether this weakness permits the  
alternation of a few characters within a message is unknown.  Even a  
small modification could permit exploits to take advantage of the  
trust established.  With email, bad actors may also have access to a  
corpus of valid messages, which might also alter the level of  
protection achieved.  Protocol semantics should assume failure  
scenarios.  There are possible failure modalities within the key  
algorithm and the canonicalization, although this is not to suggest  
these algorithms are readily exploitable today.  Simply imagine a  
future exploit is within the realm of possibilities.

While DKIM's great strength is the scalability of cryptographic  
algorithms requiring little interaction, protection does not extend  
to the message routing information.  Of course the ability to replay  
messages is a major risk factor.  Replay allows a single exploit to  
be magnified.  It is not practical to filter on the signature, as  
messages sent to a list may generate tens of thousands of messages  
with the same signature and From header.  : (

Also imagine in a few years messages will not be accepted by major  
ISPs without a DKIM signature.  By then every MUA and MTA handles  
messages according to their signing-domain.  At some point, people  
will once again consider links in their financial institution's  
messages to be safe to click.  While an expectation of trust is the  
goal of DKIM, trust also creates a target.

Imagine hidden domain names in links can be altered using a new  
inflection technique based upon a lossy property of the hash.  (This  
is only speculation.)

As reports of this exploit become known, financial institutions  
wishing to retain trust adopt a stronger function, but must place two  
signatures on their message to ensure acceptance.  Atlas their  
customers will not benefit from this improvement until all messages  
using the new algorithm are accepted and all messages using the older  
algorithm are refused.

---
To bridge the gap between exploit and universal transitioning to the  
new algorithm, there must be a means to determine whether a bad actor  
has issued a message sans the stronger algorithm.  Mark keys primary/ 
secondary.  Accept no message with only the secondary signature/key.   
If only the secondary algorithm is known by the verifier, security  
can be increased by also checking that the sender offers keys for  
this unknown algorithm.
---

Paul's idea seems more complex and is dubiously fragile.  The weaker  
algorithm must encompass the stronger unknown algorithm.  It makes no  
sense to have the stronger unknown algorithm encompass the weaker  
signature.  This strategy makes an assumption with respect to the  
nature of the exploit.  Using primary/secondary flags and consistent  
algorithm designations ensures a quick and orderly repair always  
remains practical.  That property does not seem assured by the scheme  
suggested by Paul.

-Doug

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 05 Apr 2006 06:49:44 -0500

> least whether the signer agrees.

Correct!  That is my view on the matter also.

-- 
Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 05 Apr 2006 11:29:58 -0500

> that, and MUST NOT is not needed. If we use "SHOULD NOT", we need to
 > say when it is OK to do it anyway. Proposal: "To avoid deleting
 > information that might be valuable to the recipient, signers SHOULD
 > NOT remove..."

Yes.  With that change and the previous "SHOULD" becoming "should" as 
discussed by Stephen and Mike I think this text is very good.

-- 
Arvel

---

From: Dave Crocker <[email-masked]>
Date: Wed, 05 Apr 2006 09:36:20 -0700

> discussed by Stephen and Mike I think this text is very good.

the case of a should does not change its semantics.

if the text specifies behavior, it is being normative.

d/

-- 

Dave Crocker

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 05 Apr 2006 11:50:27 -0500

> if the text specifies behavior, it is being normative.

Are you saying a 'SHOULD' and a 'should' have essentially the same meaning?

-- 
Arvel

---

From: Dave Crocker <[email-masked]>
Date: Wed, 05 Apr 2006 10:01:23 -0700

> Are you saying a 'SHOULD' and a 'should' have essentially the same meaning?

No.

I am saying that they have *exactly* the same meaning.

English does not distinguish semantic based on case and the IETF usage does not 
change the English.  The relevant RFC that specifies the use of these normative 
words does note that they are often in upper case, but it does not specify any 
distinction between upper and lower case.

d/

-- 

Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Wed, 5 Apr 2006 10:20:35 -0700

On Apr 5, 2006, at 4:49 AM, Arvel Hathcock wrote:
>> don't.  That choice is the validator's and it does not matter in  
>> the least whether the signer agrees.
>

A signer may need to add two signatures at differing strengths when  
responding to an exploitation risk while also ensuring their  
continued general acceptance when few verifiers have adopted a newer  
algorithm.

- A verifier is _expected_ to accept various levels of signature  
strength.

- A verifier _may_ consider some messages "unsigned" when the  
strength of the signature is deemed by verifier to be too weak.

- When a significant portion of messages are signed at some level, it  
will be problematic to dismiss these signatures.

- A widely used signature strength may be deemed unsatisfactory by a  
signer who responds by offering _two_ signatures.

- Until either the verifier is able to exclude the signature with the  
weaker algorithm, or the signer is able to apply only a single  
signature, the stronger of the two signatures will not offer added  
protection.

The loss of protection is due to a lack of signer communication to  
the verifier.  Without causing a sizable disruption, this missing  
information will create perhaps a sizable period of exposure to an  
exploit well beyond the control of the signer.  The general design  
should minimize interchanges needed to communicate a desired strength  
offered by the signer.  This communication will prevent a "down- 
grade" exploitation from being successful.  This information can be  
carried in a number of ways.

This information can be carried within the key of the weaker  
signature.  An "alternative algorithm" field could be added to  
indicate this signature is _always_ accompanied by a signature based  
on this alternative algorithm.  A primary/secondary flag does this as  
well, and permits a general matrix of options while consuming a  
single bit of information.

Wrapping a stronger signature with a weaker signature assumes there  
is only a partial failure of the weaker algorithm.

Not all mail is the same.  Resources expended to compromise some  
email may be focused and affect only a small percentage of the  
signers.  DKIM should ensure this targeted minority of critical email  
signers can quickly respond, and that verifier are not susceptible to  
a "down-grade" exploit.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 5 Apr 2006 10:25:51 -0700

On Apr 5, 2006, at 9:36 AM, Dave Crocker wrote:
>> association
>> Yes.  With that change and the previous "SHOULD" becoming "should"  
>> as discussed by Stephen and Mike I think this text is very good.
>

Perhaps there should also be some advice give with respect to the  
maximum number of signatures verified then.  There should be metric  
that can be applied with respect to the potential for targeted  
network amplification.

-Doug