Subject: [ietf-dkim] -base status slides (updated)

From: Eric Allman <[email-masked]>
Date: Tue, 21 Mar 2006 10:09:15 -0600

Enclosed are the updated status slides for the discussion on 
draft-ietf-dkim-base-00.  The brown text indicates updates.  Any 
errors are mine alone (although the slightly fractured jabber log 
didn't help out much).

eric

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Mar 2006 08:35:34 -0800

I'm really astonished that an open item that had no list discussion that
I can find and that is backward incompatible with -allman-01 is being
"accepted". Why? Worse, is that there is absolutely no reason why we
need to break existing compatibility to achieve the goal of being able
to determine whether it's the header or body that's broken. Nor does it
appear that anybody's thought through which -- header or body --
actually more likely to break in transit.

I have for quite some time been placing a hash of the headers alone in
the DKIM signature in an unassigned tag (X= in this message) to help
me determine whether it's the headers or the body that broke on a failed
signature. It's cheap: I just call SHAx_Final when the headers are
hashed; it's unobtrusive: it doesn't require that we change our current
hashing mechanism; and it doesn't bring up any nettlesome issues with
l= which are tricky.

Given this, I consider the adoption to be seriously harmful to our
existing implementations, and counterproductive.

		Mike

---

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Mar 2006 15:03:02 -0500

> "accepted". Why?

As a WG chair:
As we said in the IETF session and in the Jabber room, nothing "decided" 
at the IETF meeting is final until the issue is confirmed on the mailing 
list.  All that was "accepted" in the meeting is that the consensus in 
the room was to favour this change.

We are now (thank you for starting it, Mike) discussing it on the 
mailing list.

> hashing mechanism; and it doesn't bring up any nettlesome issues with

As a WG participant:
I don't see the problem you have, though.  In particular, why is it 
better to store a header hash in a tag in DKIM-Signature than it is to 
store a body hash there?  It seems to me that the combination of a BODY 
hash and z= will give the best diagnostic combination.  l= seems a red 
herring (but explain, if I'm wrong), since the signer and verifier must 
already deal with deciding which part of the body contributes to the 
hash, whether they then hash it separately or not.

Further, there are other reasons it might be rather nice to have the 
body hash.  For one, it means that the verifier can start validating the 
sig after having read the header-terminating CRLF, without yet having to 
read the body, thus allowing the signature validation to be done in 
parallel with the reading of the body (which may be significant with 
large bodies).  Related to that, it means that the verifier, if it has 
decided to trash the message, can do so by routing the body to /dev/null 
as soon as it's made that decision, rather than having to write the body 
to disk (or keep it in memory) while computing the hash.  Third, as was 
pointed out, a sender could hash a large body once and send it multiple 
times, possibly saving a lot of time/effort.

I don't see it as a big compatibility issue.  If this be put in as a 
"bodyhash=" tag (yes, we'd use a single letter, but never mind that for 
now), a verifier could simply tell by the absence of that that this is 
an allman-01 signature, and could easily verify it anyway.  We could 
even put a non-normative suggestion in the spec to that effect.

So it seems to me that this doesn't harm existing implementations, 
because it provides a smooth transition and not an abrupt 
incompatibility.  And it seems to me that it provides some useful 
benefits.  As a participant, I support it.

Mike, rebuttal?
Others, comments?  Are others worried about this introducing a damaging 
incompatibility?

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: Jim Fenton <[email-masked]>
Date: Tue, 21 Mar 2006 12:17:18 -0800

Just in the interest of accuracy...

Barry Leiba wrote:
> Third, as was pointed out, a sender could hash a large body once and
> send it multiple times, possibly saving a lot of time/effort.

This doesn't depend on the new hashing proposal.  A signer could do this
under the current proposal.

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Mar 2006 20:24:35 +0000

> under the current proposal.

Really? I thought the structure of allman-01 was to hash the
catenation of some-header-stuff, then the body then the
DKIM-signature stuff. In that case, the body hash is not useful,
at least with any standard hashing API.

S.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 21 Mar 2006 14:35:46 -0600

> at least with any standard hashing API.

That is correct.

base:
,----
| In all cases, the header fields of the message are presented to the
| signing algorithm first in the order indicated by the signature
| header field and canonicalized using the indicated algorithm.
'____

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Mar 2006 12:37:26 -0800

> hash, whether they then hash it separately or not.

Well for one very big reason: it doesn't break current interoperability.
As I understand the proposal -- and there's nothing written down, so
sorry if I get this wrong -- you:

1) bodyhash=SHAx(body);
2) SHAx(h=headers)
3) SHAx(DKIM-SIGNATURE where (B=bodyhash));

This is very different from the current method, and a naive receiver
would *not* compute the new signature correctly.

The method I outlined -- and have implemented for around 6 months
or so -- does not break backward compatiblity and achieves the goal
of determining if the breakage is in the headers or not.

> times, possibly saving a lot of time/effort.

But is any of this worth breaking backward compatibility? I don't think
so. We considered a *lot* of these issues in the days leading up to the
merger of DK and IIM, I really don't see a very compelling reason to
change them again.

I'm fairly certain that the header hash can provide this short cut as
well, though I'm not sure that it's worth it.

> even put a non-normative suggestion in the spec to that effect.

If my receiver as it stands today cannot verify a signature with this
proposal, it is _not_ backward compatible. Also: multiple different
methods of achieving the same functionality is the enemy of security
protocols (or, arguably, all protocols).

> benefits.  As a participant, I support it.

If this breaks receivers as they exist today, I see a lot of harm.

		Mike

---

From: Jim Fenton <[email-masked]>
Date: Tue, 21 Mar 2006 12:41:16 -0800

I stand corrected; hadn't considered the order things are being
presented to the hash algorithm.  Thanks for keeping me honest.

-Jim

Douglas Otis wrote:
> NOTE WELL: This list operates according
> tohttp://mipassoc.org/dkim/ietf-list-rules.html
>

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Mar 2006 12:41:12 -0800

> at least with any standard hashing API.

I'm sort of missing why this is an interesting feature. Reusing the
hash of the body would only help if you were generating multiple 
signatures. I suspect that the RSA signing operation overwhelms the
SHAx cost by a very good bit on your average size of body. That
and it's not like we're signing for, say, individual rcpt-to's where
that sort of amortization might be a nice optimization.

		Mike

---

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Mar 2006 16:16:20 -0500

> signatures.

Or using the same body in multiple messages.  Suppose "Company I", say, 
is sending a (legitimate, opted-into) mass-mailing of a 70 MB video file 
to, say, 200,000 opted-in recipients.  Suppose also that for some reason 
it has to batch these with different headers, so it can't just sign the 
whole message once.  Saving the work of hashing that 70 MB video 
multiple times would be nice.

I don't consider this a compelling reason (because I think most of these 
cases could -- and would -- just send identical messages, and could just 
hash once in either case)... it's just another reason beyond the others, 
which I do find compelling.

 > I suspect that the RSA signing operation overwhelms the
> SHAx cost by a very good bit on your average size of body.

But that doesn't matter, because we're not RSA-signing the body, only 
the hash.  So it's only the overhead of the hashing that matters.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Mar 2006 16:24:55 -0500

> Well for one very big reason: it doesn't break current interoperability.
...
> would *not* compute the new signature correctly.

That's correct; it would not -- the verifier would have to change to add 
this method of verifying, and could remove support for the allman-01 
version when it's satisfied that it's not seeing them any more.

You (Mike) clearly see this as more of a problem than I do.  The 
compatibility I want to be careful to maintain is this:

1. Continue to be able to use existing DNS records.

2. Make the transition to the IETF spec easy by making sure that 
verifiers can verify both old and new sigs without much difficulty, and 
that signers can, therefore, make their transition when enough verifiers 
have done theirs.

Even given that, I wouldn't advocate a change that means verifiers have 
to have two ways of verifying during the transition... if I didn't think 
it worth it.  In this case, I do think it worth it.

> of determining if the breakage is in the headers or not.

But it doesn't do any of the other nice things that I outlined.

What would allow it, with no transition needed, would be to hash the 
body and put it in the header tag... and then continue to do the 
full-message hash as now.  I think that's a non-starter, though, because 
it requires hashing the entire body twice (once by itself, and once with 
the header stuck on).

Barry

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Mar 2006 13:36:19 -0800

> the hash.  So it's only the overhead of the hashing that matters.

But you'd assumedly need a new RSA signature per message in order
for this to make any sense. To be pedantic:

CostRSAsign = 1
CostSHAx    = .1

For message one, cost = 1.1, for message 2-n, cost = 1.0/msg -- big
whoop. These aren't accurate, just illustrative.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Mar 2006 13:53:46 -0800

> that signers can, therefore, make their transition when enough verifiers 

I find this "enough" to be an *extremely* squishy concept. When is
"enough" enough? How can a signer determine such a thing? Who would
be brave enough to go first? We have to keep in mind that email has
no feedback loop, so it is *extremely* prone to entropy.

My understanding in the chartering phase is that there was a great
deal of desire to not make backward incompatible changes unless they
were really, really needed. Ie, for things like security botches, and
the like. This is much more of an enhancement and to my mind a fairly
marginal one at that. Consider this: this will be setting the
precedent on what is acceptable for breaking backward compatibility.

> it requires hashing the entire body twice (once by itself, and once with 

I'm far from convinced that _any_ permutation of this is worth breaking
backward compatibility. None of the reasons you gave seem compelling to
me. Having a way to detect which broke -- header or body -- does not
require breaking backward compatibility.

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Tue, 21 Mar 2006 16:39:22 -0600

> whoop. These aren't accurate, just illustrative.

For SHA-1, a rough estimate of the overhead seems to suggest the hash  
is predominate at about 100KB messages.  With SHA-256 this crossover  
might become 50KB.  It does suggest that distributing larger messages  
will increase overhead by a factor of recipients without a means to  
mitigate the HASH algorithm for larger messages.

In terms of adding a new header at subsequent stages, this parameter  
remaining unchanged in a new signature to encompass the new header  
also shows that the body of the message is not being changed.  If one  
signature fails due to the HASH not matching, it can be assumed all  
signatures will fail due to a change that has been made in the  
message body.  This change may help facilitate processing signatures  
that wish to securely add information to the message.  Rather than  
causing a cascade of failures being processed, this effort can be  
quickly short-circuited.  When the HASH in each signature are  
different, then looking for a signature with a matching HASH also  
short-circuits the discovery effort which also reduces the work  
caused when multiple signatures are allowed to exist within a message.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Mar 2006 22:46:51 +0000

> precedent on what is acceptable for breaking backward compatibility.

You are correct that this is an enhancement and not a bug-fix.

But if the WG consensus turns out to be for it, then that's
where we end up, right?

> me. 

That's a fair position. Others may disagree, equally fairly.

However, given that we have agreed to basically move to sha256,
signers who use sha256 will be signing incompatibly with allman-01
verifiers so I don't see why this change would be significant,
following on from that change.

 > Having a way to detect which broke -- header or body -- does not

Sort-of. Adding the putative "X=" header-hash you mentioned would
also require a verifier to do more than allman-01, so detecting
which is broken would require a verifier change, although such
signatures would remain compatible with allman-01 as you point
out.

I'd be interested in more opinions, including those in the room
yesterday, who might have changed their minds, or not...

S.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Mar 2006 14:59:01 -0800

> But if the WG consensus turns out to be for it, then that's

During the chartering phase, the key concern that I -- and I
think many others -- was introducing gratuitous backward
incompatible changes from allman-01. To date, we've contemplated
two changes:

1) use of relaxed over nowsp
2) sha-256

Both security related. Both _necessary_.

> following on from that change.

I don't consider sha256 a very good counterpoint: we're making
that change because we _have_ to, due to forces outside our
control. This change is in our control, however.

As I said, this would set the barrier for incompatible changes
*much* lower than before, and I worry greatly about the stability
of the spec were that to happen.

> signatures would remain compatible with allman-01 as you point

It does not break current implementations though. As Murray
and Arvel's implementations can attest. The current proposal
will break all of our implementations. Needlessly, IMO.

		Mike, who is not even sure that
		 we really need anything along these
		 lines long term, which is why I never
		 brought up my header hash hack up as a
   		 possible addition to -base.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Mar 2006 23:29:44 +0000

Mike,

Michael Thomas wrote:
> incompatible changes from allman-01. 

This is not a gratuitous change since there are folks who
believe it offers sufficient advantage. Whether it is
warranted is another issue, but I can't see that that
description is fair.

> control. This change is in our control, however.

That's not my point. To reiterate: *given* that we already have
a backwards incompatible change, your argument that this is
another such, is much less telling.

That doesn't affect your argument that this may be a slippery
slope of course, but the two are separate.

> of the spec were that to happen.

That's a fair point.

> and Arvel's implementations can attest. 

Again, I didn't say your "X=" broke anything. I said that it
requires a change in the signer and verifier in order to detect
which of the header or body broke the signature.

 > The current proposal

s/break/change/ is true, but I'm quite sure folks could code
up the new signature scheme just as well, so I don't find that
argument very telling since you need to update the signer and
verifier code at some point to comply with the eventual RFC.

As I read it, the core of your argument is that you don't
find the change compelling and that you are concerned about
the precedent. Both are reasonable points to make, but neither
really touches upon signature format incompatibility, given
the sha256 change, IMO.

Again, I'd like to hear more voices, so that we can figure
where the consensus lies.

Stephen.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Mar 2006 18:43:19 -0500

> which of the header or body broke the signature.

Well, but that's irrelevant.  Mike's (correct) point is that if the 
verifier doesn't care about the new information provided, the verifier 
doesn't have to change.  With the proposal on the table, all verifiers 
would have to migrate.

I agree, though, that since the verifiers have to migrate anyway (to 
SHA-256), I think this is a less-than-compelling reason not to do this.

The "slippery slope" reason is more compelling.

Barry

---

From: Tony Hansen <[email-masked]>
Date: Tue, 21 Mar 2006 19:08:15 -0500

Okay, I've implemented the current spec, and extended it for sha256. But
it was done in such a way that I am still supporting sha1. I feel that
this proposed suggested change falls in the same category as moving from
sha1 to sha256, and should be treated the same way:

	Receivers MUST implement bodyhash= and b=
	Signers MUST implement bodyhash=
	Signers SHOULD use bodyhash=

We need to make sure that we understand the proposal thoroughly. Some of
the descriptions so far have been worded in a way that their meaning
could be misconstrued.

That's my 2c.

	Tony Hansen
	[email-masked]

Barry Leiba wrote:
>>> It does not break current implementations though. As Murray and
>>> Arvel's implementations can attest.
>>
> verifier doesn't care about the new information provided, the
> verifier doesn't have to change. With the proposal on the table, all
> verifiers would have to migrate.
>

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 21 Mar 2006 22:29:22 -0800 (PST)

> at least with any standard hashing API.

You're correct. So the right way to do body hash separately is to
include body hash as separate item (i.e. digest header field) and
sign that within full signature.

Its nice to see you finally come around and adapting further META 
signing structure (and you have already adapted canonicalization
method from my draft by now...) of course you will probably never
admit where this is all coming from ...

But to the point, regarding why this signing system is better:
  1. It allows to know which part of message has been changed (*)
  2. It decreases resources necessary to sign multiple emails
     from the same place with with largely same email body
     (BTW - this includes mail list processing and is probably
      where it would become most useful).
  3. It slightly decreases resources for those adding additional
     signatures in transit i.e. 3rd party signers (another advantage
     for mail list servers I guess...).
  4. It allows to do cryptographic verification at the time when
     email header has been received even if entire email body
     has not been received. So:
      a. For system where email header is sent first ahead of
         email body (Hector is working on this and many others
         proposed it and written drafts on it before too).
      b. Similar to above optimization where mail server would start
         cryptographic verification immediately when header data is
         received while its still continuing to process additional
         data during DATA command. For large email on slow connection
         (wireless clients, satellite) this could be noticeable
         improvement.

There are some other possibilities that are also open for example
its possible to verify signing server's public key even if email body
has been changed. This allows to verify at least certain information
about email which could be useful for a filtering (this can also
be abused by bad guys of course).

Going further META design allows to actually have multiple digests created 
in different ways (I never explained about it, but its in my original 
design notes) as well as digests with different hash algorithms (this I 
decided to move directly to content-digest draft and as you will see in
upcoming version 1).

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 22 Mar 2006 09:11:20 -0500

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

> where the consensus lies.

I prefer to go with the proverbial Engineering/QA motto:

      "Getting it right... the first time."

I think too much has been made of the early adoption of a DKIM-only system
that is obviously premature in its engineering that will most certainly have
a higher cost in implementation and obtaining effective results.   We are
talking about what? 5-10?  early adopters? which is really just based on the
1-3 source codes (think about that single sourcing), out of what potentially
hundreds of millions of domains in a widely adopted network?

My input is basically to place more consideration on the #1 victims of this
protocol: the receivers.  They are the ones that are going to be have to
make some real big decisions on how to best handle a potential "new found"
avalanche of DKIM-signed messages

If we were to consider the TCO of DKIM, it would easy to show how the
current model is more expensive when it fact, it doesn't have to be.

Current model:

  TCO(DKIM1) =  TCO(HASH-BODY)+ TCO(HASH-HDR) + TCO(SSP)

The order of the processing above is important.

The more optimal model when considering order is:

  TCO(DKIM2) =  TCO(SSP) + TCO(HASH-HDR) + TCO(HASH-BODY)

There is doubt in my mind:

  TCO(DKIM2) <= TCO(DKIM1)

The reasons are straight forward:

  - SSP processing offers short circuiting of remaining
    processing overhead

  - HASH-HDR processing offers short circuiting of remaining
    processing overhead

and so on.

So think of the verifiers. Signing is the easiest part.

Get it right.  The cost will be much higher later cleaning up the "mess"
later.

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

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 22 Mar 2006 09:23:18 -0500

Oy vey! Urghhhhhhhhhh! Correction! I meant there is "no doubt" in my mind.

----- Original Message ----- 
From: "Hector Santos" <[email-masked]>

> There is [NO] doubt in my mind:
> 
>   TCO(DKIM2) <= TCO(DKIM1)
>

---

From: Mark Delany <[email-masked]>
Date: Wed, 22 Mar 2006 15:28:34 +0000

> That's a fair position. Others may disagree, equally fairly.

I'm not sure I see why backward compatibility is such a big deal for
the email headers.  There is a vastly larger deployment of DK and in
spite of that, changes that broke DK headers where knowingly made in
the evolution of allman-01 - even though one of the stated goals was
the same as the DKIM charter - to try and be compatible.

Now that there is a tiny set of experimental implementations and
deployment of allman-01, suddenly header incompatibility is more
important?  I don't buy the distinction as rationale against this
change or any other header change for that matter.

In fact, as I recall at the Cisco DKIM summit, the recommendation for
those wanting to experiment with implementations now was to use
allman-01 as the draft was expected to be in a state of flux and have
a number of further refinements over coming versions. In short,
everyone was expecting that it would change as the WG moved focus from
threats to base.

I agree with Barry that the main compatibility leverage we can make is
to Selectors deployed by the 10,000 or so domains that do DK signing.

Mark.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Mar 2006 09:34:35 -0600

At 11:29 PM +0000 3/21/06, Stephen Farrell wrote:
>believe it offers sufficient advantage.

Exactly. People have listed multiple good results from the proposal. 
So far, the only negative result is that people who have written 
software to the -00 draft will have to change it.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Wed, 22 Mar 2006 08:03:42 -0800

Paul Hoffman wrote:
> Exactly. People have listed multiple good results from the proposal. So 
> far, the only negative result is that people who have written software 
> to the -00 draft will have to change it.

I guess that's an inconsequential consideration.

But you forget to mention that the combinatorial explosion problem that
results with each incompatible change. And that's doubly true since the
bar is being set so low for any subsequent incompatible change. And let
us not forget that the single most difficult thing to achieve
interoperability is the canonicalization/hashing.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Wed, 22 Mar 2006 10:16:42 -0600

> But if the WG consensus turns out to be for it, then that's

Stephen, since Michael did not suggest a challenge to the process, it's not 
clear why you felt it necessary to put things in those terms.

Michael raised a concern.  A legitimate concern, if I may say.

We should deal with it the same way we deal with any other concern.

> following on from that change.

Perhaps you missed the fact that this particular enhancement is being specified 
in a way that permits messages signed using sha-1 to be accepted by validators 
who implement the IETF's version of DKIM?

This difference between a compatible enhncement and an incompatible enhancement 
is quite basic and it would be quite useful not to confuse them.

> signatures would remain compatible with allman-01 as you point

The issue is not whether the verifier changes but whether mail from a pre-ietf 
signer can be validated by a post-IETF implementation.

d/
-- 

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

---

From: Dave Crocker <[email-masked]>
Date: Wed, 22 Mar 2006 10:25:35 -0600

> to the -00 draft will have to change it.

Paul,

Am I correct in reading your "the only negative result" language as implying 
that that result is minor?

d/

-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Wed, 22 Mar 2006 11:03:28 -0600

> everyone was expecting that it would change as the WG moved focus from

Mark,

There is a difference between noting that the IETF specification is in flux, 
versus predicting that the IETF will produce a final specification that breaks 
the ability to have a signer who uses the pre-ietf spec be validated by an 
implementor of the post-ietf draft.

So far, we have not modified DKIM to cause this breakage.  The current proposal 
will cause this breakage.

We should not break the pre-ietf to post-ietf interoperability without extremely 
good cause.

d/
-- 

Dave Crocker

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Mar 2006 11:01:23 -0600

At 10:25 AM -0600 3/22/06, Dave Crocker wrote:
>Am I correct in reading your "the only negative result" language as 
>implying that that result is minor?

No.

---

From: Russ Housley <[email-masked]>
Date: Wed, 22 Mar 2006 12:30:33 -0500

Dave:

This topic was addressed at great length during development of the 
DKIM charter, which says:

    Experimentation has resulted in Internet deployment of these
    specifications. Although not encouraged, non-backwards-compatible
    changes to these specifications will be acceptable if the DKIM working
    group determines that the changes are required to meet the group's
    technical objectives.

If changes are needed, make them!  Be aware of the backward 
compatibility issues, but this cannot be used to stifle discussion or 
innovation.

Russ

At 12:03 PM 3/22/2006, Dave Crocker wrote:
>There is a difference between noting that the IETF specification is 
>in flux, versus predicting that the IETF will produce a final 
>specification that breaks the ability to have a signer who uses the 
>pre-ietf spec be validated by an implementor of the post-ietf draft.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Mar 2006 11:48:27 -0600

On Mar 22, 2006, at 11:03 AM, Dave Crocker wrote:

> So far, we have not modified DKIM to cause this breakage.  The  
> current proposal will cause this breakage.
>
> We should not break the pre-ietf to post-ietf interoperability  
> without extremely good cause.

Dave,

It should be noted that by including the hash parameter within the  
signature header, this provides the same level of change as that of a  
SHA-1 modification.  This parameter indicates a new sequence is being  
used to develop the hash in addition to a new hash algorithm.  While  
an older implementation will not be able to understand this  
modification, neither will it understand the SHA-256.  The newer  
implementation, in an effort to remain backward compatible, could key  
upon the hash parameter existing or not within the header to know  
which sequence of hashing was used.  I am not necessarily  
recommending this strategy, but it is one that could be use to retain  
the same level of breakage as was caused by the SHA change.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Wed, 22 Mar 2006 10:04:27 -0800

Dave Crocker wrote:
> There is a difference between noting that the IETF specification is in
> flux, versus predicting that the IETF will produce a final
I don't think there's anything that prevents an implementor of the
post-ietf draft from verifying an allman-01 signature.  You can tell
which is being used by looking for the presence/absence of the hash
tag/value in the signature header field.
>
> So far, we have not modified DKIM to cause this breakage.  The current
> proposal will cause this breakage.
I would be considerably more concerned if there was some
non-self-evident change to the signature, like if we had decided to hash
the body before the signed header fields, and had not also incremented
the signature version number.

-Jim

---

From: Tony Hansen <[email-masked]>
Date: Wed, 22 Mar 2006 13:24:31 -0500

"Good ideas never die, they just get reused in another protocol."

META has several good ideas in it that are not (yet?) in DKIM; this one
is certainly related to what you have in META.

	Tony Hansen
	[email-masked]

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 22 Mar 2006 13:10:51 -0600

> 1. Continue to be able to use existing DNS records.

Yes.  That is my position also.  The most important thing to protect are 
the existing thousands of DK selectors currently in use.

 > following on from that change.

I think that's a fair point.  Perhaps this change could be handled in a 
similar fashion to the sha1/sha256 change.

-- 
Arvel

---

From: Michael Thomas <[email-masked]>
Date: Wed, 22 Mar 2006 11:25:53 -0800

Russ Housley wrote:
> Dave:
> 
> This topic was addressed at great length during development of the DKIM 
> charter, which says:
> 

Define "needed". If the standard of "needed" is "required to make
the protocol viable", then this is not "needed". If "needed" means
"anything we feel like changing, we can change", then the words in
the charter are meaningless.

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Mar 2006 13:43:24 -0600

On Mar 22, 2006, at 1:10 PM, Arvel Hathcock wrote:

> Yes.  That is my position also.  The most important thing to  
> protect are the existing thousands of DK selectors currently in use.

Extending the q=dns to q=dns,dns-b could be a method to indicate the  
presents of a binary version of the key RR is available without  
immediately depreciating use of TXT keys, for example.  Both the  
change of the hash function and the sequence of the hash function  
allows upward changes, while still being able to handling messages  
from prior versions.  In the case of DNS RR, there could be  
additional information only available in the binary version.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Wed, 22 Mar 2006 14:07:19 -0600

Russ,

> This topic was addressed at great length during development of the DKIM 

I am not sure what topic you think was addressed.  Since no one has suggested 
that the working group effort lacks authority to make changes I can't guess what 
you are referring to.

Since there already are voices making clear that the question of compatibility 
is important, here, and since asking that question does not imply that the 
outcome is pre-determined, I am really curious why Stephen and now you seem so 
focused on it.

> compatibility issues, but this cannot be used to stifle discussion or 

Who has been trying to "stifle discussion or innovation" and how have they been 
doing that?

If you answer is "no one" then why did you feel it necessary to utter this 
directive?

d/
-- 

Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 22 Mar 2006 12:22:08 -0800

Dave Crocker wrote:
> Who has been trying to "stifle discussion or innovation" and how have 
> they been doing that?

I have, apparently. I guess that the mere act of questioning whether
backward compatibility has any weight against wheel reinvention
is considered stifling.

		Mike, stifled stifler.

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 22 Mar 2006 16:14:11 -0500

----- Original Message ----- 
From: "Eric Allman" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, March 22, 2006 3:47 PM
Subject: Re: [ietf-dkim] 1193 considered harmful

> My take is that making gratuitous changes is silly and should be 
> avoided.  Personally, I like "|" as a separator better than ":", but 
> that's pretty gratuitious and I would oppose such a change on 
> principle.

Ditto.

> If there weren't other required changes then I might feel 
> differently.  But the SHA-256 change means that both signers and 
> verifiers are going to have to update their software anyway.  This 
> will be just part of that update.  No extra work for the installed 
> base.

- RELAYED broke my version of the DKIM code.

- SHA-256 broke my version of the DKIM code.

- Mike's capitalized X= introduced threw us into a spin 
  until it was realized the TAGS are case sensitive. It was
  picked up as a expiration tag.  Our fault, but it can happen.

But thats all good.  Early implementators should know there is a 
possibility of changes. The charter made that clear.

> If the proposed change weren't at least some improvement then I might 
> feel differently.  But I think it is an improvement.  We can argue 
> how much of one, but that's not the point.

Ditto. I think its a big improvement over whats we have now.

> If it was impossible to provide a transition period then I might feel 
> differently.  But it's not impossible, as has been described.
> 
> In short, I'm in favor of this change.
> 
> Or perhaps I should have just said "me too".

Ditto.

---

From: Russ Housley <[email-masked]>
Date: Wed, 22 Mar 2006 16:15:45 -0500

Dave:

My concern was that you only talked about the backward 
compatibility.  In the future, please couple the backward 
compatibility issue with the other dimensions discussed in the 
charter.  For example, a statement that a backward compatibility 
concern can be avoided if we do A instead of B to meet technical 
objective C is completely appropriate.  I did not interpret you 
message in this light.

Again, the DKIM charter says:

Enough on this topic, I think.  Back to the technical discussion, please.

Russ

At 03:07 PM 3/22/2006, Dave Crocker wrote:
>I am not sure what topic you think was addressed.  Since no one has 
>suggested that the working group effort lacks authority to make 
>changes I can't guess what you are referring to.
>
>Since there already are voices making clear that the question of 
>compatibility is important, here, and since asking that question 
>does not imply that the outcome is pre-determined, I am really 
>curious why Stephen and now you seem so focused on it.
>
>>compatibility issues, but this cannot be used to stifle discussion 
>>or innovation.
>
>Who has been trying to "stifle discussion or innovation" and how 
>have they been doing that?
>
>If you answer is "no one" then why did you feel it necessary to 
>utter this directive?
>
>d/
>--
>
>Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Wed, 22 Mar 2006 15:33:55 -0600

Russ,

> My concern was that you only talked about the backward compatibility.
> In the future, please couple the backward compatibility issue with the 
> other dimensions discussed in the charter. 

Let me see if I understand the requirement you are describing:

1. Someone makes a suggestion for a change.

2. The group discusses its benefits and leans towards adoption.

3. Someone else notes that this breaks validation from pre-IETF signers.

(further steps occurred, but your rule appears to apply to this third step)

It appears that you are asserting that any such expression of concern about 
incompatibility requires repeating whatever the trade-offs are, nevermind that 
the benefits have already been expressed.

It further appears that anytime someone expresses a concern for compatibility 
with pre-IETF implementations, but fails to include other text that discusses 
this as a collection of trade-offs, you or a chair feel compelled to treat the 
concern as if it were a scope or process challenge.

Since I am not aware that any other expressions of benefit or detriment are 
automatically expected to carefully list a full set of trade-offs, please 
explain the assertion of this policy in this case.

  For example, a statement
> that a backward compatibility concern can be avoided if we do A instead 
> of B to meet technical objective C is completely appropriate.  I did not 
> interpret you message in this light.

Like Stephen, you appear to have read vastly more in my text than I put there. 
I never stated nor implied my own preference about the resolution of the current 
topic.  (For reference, I was in fact conflicted about it.)  Rather, I was and 
am concerned that incompatibilities be treated carefully.

> Again, the DKIM charter says:

Thanks for including that, yet again.  I hadn't read it carefully enough before.

d/

-- 

Dave Crocker

---

From: Russ Housley <[email-masked]>
Date: Wed, 22 Mar 2006 16:39:41 -0500

Dave:

Not exactly.  I do not want to see backwards compatibility raised as 
the sole reason for objecting to something.  I offered one way to 
approach this.  There are clearly other acceptable ones.

Russ

At 04:33 PM 3/22/2006, Dave Crocker wrote:
>>In the future, please couple the backward compatibility issue with 
>>the other dimensions discussed in the charter.
>
>It appears that you are asserting that any such expression of 
>concern about incompatibility requires repeating whatever the 
>trade-offs are, nevermind that the benefits have already been expressed.
>
>It further appears that anytime someone expresses a concern for 
>compatibility with pre-IETF implementations, but fails to include 
>other text that discusses this as a collection of trade-offs, you or 
>a chair feel compelled to treat the concern as if it were a scope or 
>process challenge.
>
>Since I am not aware that any other expressions of benefit or 
>detriment are automatically expected to carefully list a full set of 
>trade-offs, please explain the assertion of this policy in this case.
>
>
>  For example, a statement
>>that a backward compatibility concern can be avoided if we do A 
>>instead of B to meet technical objective C is completely 
>>appropriate.  I did not interpret you message in this light.
>
>Like Stephen, you appear to have read vastly more in my text than I 
>put there. I never stated nor implied my own preference about the 
>resolution of the current topic.  (For reference, I was in fact 
>conflicted about it.)  Rather, I was and am concerned that 
>incompatibilities be treated carefully.
>
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 22 Mar 2006 15:45:19 -0600

Russ Housley wrote:
  > Not exactly.  I do not want to see backwards compatibility raised as the
> sole reason for objecting to something.  I offered one way to approach 
> this.  There are clearly other acceptable ones.

So incompatibility is somehow a lesser status than any other sort of concern?

Why?

What is particularly strange is that this seems to be taking the charter 
language and using it to deprecate the concern about incompatibility, rather 
than strengthen it.

And forgive my ignorance of IETF process, but I do not recall seeing such a 
stricture from IETF management asserted previously.  After so many years, I 
doubt that anything is literally unprecedented, but this does seem pretty close.

d/
-- 

Dave Crocker

---

From: Russ Housley <[email-masked]>
Date: Wed, 22 Mar 2006 16:48:26 -0500

Very nice posting.  Thanks.

We now have another example of a message addressing backward 
compatibility in a manner that is in line with the charter, even if 
the end of the message had reached the opposite colclusion.

Russ

At 03:47 PM 3/22/2006, Eric Allman wrote:
>that's pretty gratuitious and I would oppose such a change on principle.
>
>But I'm reminded of the syntax of the sendmail.cf file.  A great 
>many years ago I realized that the syntax sucked and I should fix 
>it, but I didn't in the name of back compatibility (there were 
>perhaps a few hundred servers that would have been affected).  In 
>retrospect that was stupid.
>
>will be just part of that update.  No extra work for the installed base.
>
>If the proposed change weren't at least some improvement then I 
>might feel differently.  But I think it is an improvement.  We can 
>argue how much of one, but that's not the point.
>
>If it was impossible to provide a transition period then I might 
>feel differently.  But it's not impossible, as has been described.
>

---

From: Michael Thomas <[email-masked]>
Date: Wed, 22 Mar 2006 13:54:39 -0800

> this.  There are clearly other acceptable ones.

Please. I brought this issue up. It was not the *only* objection,
and I *did* bring up an alternate way to solve the problem without
breaking backward compatibility, at least until the motivation
morphed into something other than the originally stated goal.

		Mike

>> It appears that you are asserting that any such expression of concern 
>> about incompatibility requires repeating whatever the trade-offs are, 
>> nevermind that the benefits have already been expressed.
>>
>> other text that discusses this as a collection of trade-offs, you or a 
>> chair feel compelled to treat the concern as if it were a scope or 
>> process challenge.
>>

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 22 Mar 2006 15:56:24 -0600

> Or perhaps I should have just said "me too".

"me too".

-- 
Arvel

---

From: Eric Allman <[email-masked]>
Date: Wed, 22 Mar 2006 14:47:34 -0600

But I'm reminded of the syntax of the sendmail.cf file.  A great many 
years ago I realized that the syntax sucked and I should fix it, but 
I didn't in the name of back compatibility (there were perhaps a few 
hundred servers that would have been affected).  In retrospect that 
was stupid.

eric

---

From: Russ Housley <[email-masked]>
Date: Wed, 22 Mar 2006 17:10:07 -0500

No Dave. Again, the DKIM charter says:

If you had said that the group's technical objectives could be met 
without introducing an non-backwards-compatible change, then we would 
not be having this dialogue.  You only talked about the backward compatibility.

Russ

At 04:45 PM 3/22/2006, Dave Crocker wrote:

>>sole reason for objecting to something.  I offered one way to 
>What is particularly strange is that this seems to be taking the 
>charter language and using it to deprecate the concern about 
>incompatibility, rather than strengthen it.
>
>And forgive my ignorance of IETF process, but I do not recall seeing 
>such a stricture from IETF management asserted previously.  After so 
>many years, I doubt that anything is literally unprecedented, but 
>this does seem pretty close.
>
>d/
>--
>
>Dave Crocker

---

From: Russ Housley <[email-masked]>
Date: Wed, 22 Mar 2006 19:39:14 -0500

Mike:

I have no problem with this posting.  It does exactly what I am 
requesting.  The message would not have been sent if Dave followed 
the format that you did.

I especially like the part where you said:  "... there is absolutely 
no reason why we need to break existing compatibility to achieve the 
goal of being able to determine whether ..."

I am sorry that you somehow feel that I have attacked you.  This 
exactly the kind of discussion that is in line with the charter.

Russ

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 22 Mar 2006 22:01:27 -0600

Would it be possible/wise to just not do this incompatible change when 
signing with sha1?  Since we are not going to recommend sha1 as the hash 
alg in the ietf-dkim product anyway and since all the pre-ietf dkim 
signers and verifiers all use sha1 why not just skip this change 
completely when using sha1?  Does that create a ton of problems that I'm 
not seeing?  Perhaps it's not desirable to have the base spec document 
two separate ways to hash messages (one when using sha1 and another when 
using anything else).

-- 
Arvel

---

From: Mark Delany <[email-masked]>
Date: Thu, 23 Mar 2006 08:32:03 +0000

> signing with sha1?  Since we are not going to recommend sha1 as the hash 

That could work of course, but I don't think it's an ideal way of
doing it in such a new protocol as that approach effectively makes the
algorithm choice a surrogate version.

if a=rsa1 then interpret rest of content in this way
if a!=rsa1 then interpret rest of content in another way

Six months down the road we have the same discussion about some other
compatibility issue and someone suggests that an l=-1 (just as an
example) might suffice to indicate the old way of doing things. Then
you have:

if a=rsa1 and l=-1 then interpret rest of content in way One
if a=rsa1 and l!=-1 then interpret rest of content way Two
if a!=rsa1 and l=-1 then interpret rest of content in way Three
if a!=rsa1 and l!=-1 then interpret rest of content in way Four

etc, etc.

It's not clear to me that DKIM has so much inertia that we need to
accrete these sort of contortions yet.

Mark.

---

From: Mark Delany <[email-masked]>
Date: Thu, 23 Mar 2006 09:24:15 +0000

On Tue, 21 Mar 2006, william(at)elan.net allegedly wrote:

> signing structure
...

> of course you will probably never admit where this is all coming
> from ...

Of course we will. The idea is merely a variant of Content-MD5.

What Meta-whatever-it-is has to do with that admission I do not
know. Are you suggesting that Content-MD5 derived from Meta-whatever?

Mark.

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 23 Mar 2006 03:35:18 -0800 (PST)

> Of course we will. The idea is merely a variant of Content-MD5.

And domainkeys is variant of PEM with difference that PEM specified use of
several PKIs, one of them based on specialized binary record for retrieving
public key from DNS, where as domainkeys came up with reusing TXT record for
it and based it entirely on DNS. As Tony mentioned - ideas  don't die, I
guess they just get patented and only then reused in another protocol :)

(BTW - I'm not saying you knew about PEM when you came up with domainkeys, 
reinvention of same idea 10 years after is not unusual)

> know. Are you suggesting that Content-MD5 derived from Meta-whatever?

One of the META's primarily features is separation of header and body
canonicalization and hash creation for email signature - so the signature
then is truly header-only that incorporates one or more body hash digests
with that hash data available as separate item in email header.

As far as I know what is at metasignatures.org is the first published design
that used this concept, although as Phil said and I believe him it was also
used by others in their private non-published efforts.

As far as Content-MD5 it is well mentioned in content-digest draft as direct
origin for Content-Digest header field with Content-Digest being done partly
because Content-MD5 needs to be replaced by something more advanced and not
tied to specific hash algorithm in field name.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Mar 2006 13:01:39 +0000

william(at)elan.net wrote:
> reinvention of same idea 10 years after is not unusual

I think that maybe this is a sign that the discussion has
gone around enough. So maybe we can give this one a rest
unless there're new voices or ideas (like Arvel's posting).

FYI, Barry and I figured that we'd "officially" dispose of
the issues discussed at the meeting whenever we make the
meeting minutes final. The draft minutes will contain the
meeting-room consensus for each. So, I'm not trying to
say this is an accept or reject now, but we are discussing
it a lot.

S.

PS: Not trying to get at you William, the design archeology
discussion just kind of jumped out at me.

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 23 Mar 2006 08:50:07 -0600

> compatibility issue and someone suggests that an l=-1

Ah, understood.  That would make for a really ugly final specification 
if it were to occur.

OK, if we don't want to go down that route, I think we can still handle 
this problem because I'm convinced that our verifiers can be taught to 
detect when the new hashing mechanism is in use and act accordingly. 
This requires a verifier update but that's already unavoidable.

-- 
Arvel

---

From: Michael Thomas <[email-masked]>
Date: Thu, 23 Mar 2006 07:09:38 -0800

Barry Leiba wrote:
> large bodies). 

I just realized this morning that this benefit is mostly a
mirage: you don't have the public key until you query DNS,
and in all likelihood the message is going to be received
by the time you get the key back (assuming it's average size).
The only way to make this a reliable feature would be to send
the key in the mail itself ala IIM.

So let me see if I can tally this up:

1) +/- can determine if body or headers are broken; - because it can
        be done in a backward compatible fashion.
2) +   can determine early on if header signature is valid; weak
        because you won't ordinarily have the key, and most especially
        not from malicious domains
3) +   can hash a body once for redistribution; a fairly marginal
        feature that might help mass mailers, but Moore's law is just
        as likely to help, um, more.
4) -   breaks backward compatibility
5) -   no way for signer to determine when it's safe to not send
       -allman-01; the longer we wait for the RFC #, the bigger this
        problem becomes
6) -   canonicalization/hashing agreement is the hardest part of the
        spec to get right from an interop standpoint.

So the way I look at it you've got one nice benefit that can be
implemented in a backward compatible way, and two benefits that
are of fairly marginal utility. The downside is that we get churn
in the part of the spec that's hardest to get right, and a not
terribly easy way for a signer to know when it's safe to deprecate
-allman-01.

If (2) were more a reliable feature this would be harder call, but
absent other upsides I've missed, I really don't see the overall
benefit.

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 23 Mar 2006 10:22:37 -0600

On Mar 23, 2006, at 9:09 AM, Michael Thomas wrote:

> I just realized this morning that this benefit is mostly a mirage:  
> you don't have the public key until you query DNS, and in all  
> likelihood the message is going to be received by the time you get  
> the key back (assuming it's average size). The only way to make  
> this a reliable feature would be to send the key in the mail itself  
> ala IIM.

There could be many more than one signature within a message.  This  
separate hash parameter feature may help to reduce the number of  
these DNS transactions.

> 1) +/- can determine if body or headers are broken; - because it  
> can be done in a backward compatible fashion.

While yes, those messages sent without this change can be determined  
by the absence of the hash parameter in the signature header.  When  
the hash is included in the signature header, the phase of the  
process that fails validation can be determined.  That clearly seems  
to be a plus.  There is a change in the hash function anyway creating  
_exactly_ the same level of change.  This added benefit of isolating  
the failure should be a major plus.

> because you won't ordinarily have the key, and most especially not  
> from malicious domains

This however provides a better clue why these signatures might  
accompany the message.  There will be breakage caused by a list  
service, for example.  This list server may add their signature that  
properly covers the message body after their flattening.

Although perhaps a rat-hole, with significant body alteration, it may  
still be practical to determine whether the initial message headers  
submitted can be verified independent of the body.  This would be  
trusting the list-server process in order to arrive at a partial  
initial submitter assurance.  Perhaps there could be a type of list-*  
headers that used to capture modified headers.

> feature that might help mass mailers, but Moore's law is just as  
> likely to help, um, more.

When signatures arrive on a message from many domains, checking the  
body hash quickly indicates which signature should be checked, as  
those that fail to match (at the various lengths) would be  
fruitless.  The traffic and delays induced by a borage of needless  
signature validations will not greatly change, where the speed of  
light contributes substantially to this overhead not affected by  
shrinking die sizes. : (

> 4) -   breaks backward compatibility

As does the SHA-1 hash change which provide the same level of breakage.

> 5) -   no way for signer to determine when it's safe to not send - 
> allman-01; the longer we wait for the RFC #, the bigger this  
> problem becomes

The SHA-1 hash represents the same issue.  A hash located within the  
signature header also indicates a change in the hash algorithm which  
is no less significant.

> 6) -   canonicalization/hashing agreement is the hardest part of  
> the spec to get right from an interop standpoint.

The body hash being separable from that of a more complex header  
hashing process should improve upon identifying where a problem  
exists.  Locating the problem facilitates maintenance of interoperation.

> implemented in a backward compatible way, and two benefits that are  
> of fairly marginal utility. The downside is that we get churn in  
> the part of the spec that's hardest to get right, and a not  
> terribly easy way for a signer to know when it's safe to deprecate - 
> allman-01.

It would seem the need to recognize SHA-256 and hash parameters  
within the signature have already caused a need to depreciate the use  
of the draft.  The reason should be rather obvious, as there will be  
messages older versions will be unable to validate.  The SHA-256  
should be enough to tell this older version it is unable to verify  
this newer version.  The inclusion of the hash does _nothing_ to  
alter this.  Inclusion of the hash parameter however helps determine  
why a message has been broken.  If this process is as hard as you  
suggest, this change is even more beneficial.

-Doug

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 23 Mar 2006 10:23:23 -0600

>        as likely to help, um, more.

For mailing lists which sign their outbound traffic surely this benefit 
is more than marginal; especially for large lists?  I don't have as much 
knowledge here as Mike and I'm no crypto expert (thank God for OpenSSL 
BTW) but isn't the hashing part what takes the longest (sorry if I'm 
wrong on that).

-- 
Arvel

---

From: Michael Thomas <[email-masked]>
Date: Thu, 23 Mar 2006 08:39:09 -0800

> BTW) but isn't the hashing part what takes the longest (sorry if I'm 

Most mailing lists that I know of produce one copy of the outgoing
mail with a large number of rcpt-to's, so it's not very important
to them. Where it might be useful is for, say, an outbound marketing
campaign where you send the spam^H^H^H^Hmessage to each recepient
individually.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 23 Mar 2006 10:55:51 -0600

Michael,

> campaign where you send the spam^H^H^H^Hmessage to each recepient

It is quite common for bulk mailing services to re-use the same body for 
multiple postings.

It provides a basic level of per-user tailoring that is quite useful.

d/
-- 

Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Thu, 23 Mar 2006 09:02:14 -0800

> It provides a basic level of per-user tailoring that is quite useful.

Isn't that what I just said?

In any case, I wonder how useful it really is because lots of bulk
mailers try to customize their message to the recipient. This seems
like a pretty marginal optimization to me.

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 23 Mar 2006 11:23:35 -0600

On Mar 23, 2006, at 10:23 AM, Arvel Hathcock wrote:

> For mailing lists which sign their outbound traffic surely this  
> benefit is more than marginal; especially for large lists?  I don't  
> have as much knowledge here as Mike and I'm no crypto expert (thank  
> God for OpenSSL BTW) but isn't the hashing part what takes the  
> longest (sorry if I'm wrong on that).

Here is an interesting link on performance.

http://www.eskimo.com/~weidai/benchmarks.html

The MB/S rating of the hashing function is therefore dependent upon  
the size of the message.  The RSA overhead is dependent upon the key  
size.

The advantage found by the hash parameter from the verification  
perspective is found when considering the related overhead related to  
weeding through a series of possibly "broken" signatures (largely  
related to more expensive DNS transactions) and various added  
signatures when this becomes more common place.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Thu, 23 Mar 2006 13:42:35 -0600

>> It is quite common for bulk mailing services to re-use the same body 
>> for multiple postings.
>>

No.  You said it might be.  I said it was.  The difference is particularly 

> like a pretty marginal optimization to me.

because this observation is the usual comment at this stage of a discussion 
about this topic, and the question is left at whether same-body/different-header 
messages are actually sent.  I am saying that they are.

This does not say that tailored bodies are not also popular.  Merely that they 
are not the only model that is used.

d/
-- 

Dave Crocker

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 24 Mar 2006 01:52:13 -0600

> and the question is left at whether same-body/different-header

Right, it's very common isn't it?  Doesn't this mailing list do it?

-- 
Arvel

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 24 Mar 2006 08:00:49 -0500

----- Original Message -----
From: "Arvel Hathcock" <[email-masked]>

> Right, it's very common isn't it?  Doesn't this mailing list do it?

But the irony, DKIM is being supported by the DMA as their ticket to
legitimacy and their wishes can be very costly.  If it wasn't obvious, the
reference is when you have a message body template like so:

   Dear  %FIRST.NAME%

   Do you suffer from %PROBLEM%?   If so, then we have %SOLUTION%
   at a cost of %COST% designed just for you!

Template variables %PROBLEM%, %SOLUTION% and %COST% is common. But
%FIRST.NAME% is not requiring each message to be individualized.

This means if you have 1,000,000 target addresses, you need either:

    1) 1,000,000 individual storage files, or
    2) A smart MTA that performs template macro substitution dynamically
       at the SMTP session.

Most models exist,  DKIM caters to #1.  #2 will require DKIM hashing at the
SMTP stage.

---

From: Jim Fenton <[email-masked]>
Date: Fri, 24 Mar 2006 05:54:29 -0800

> Right, it's very common isn't it?  Doesn't this mailing list do it?
I believe this mailing list sends the same message (including the same
header fields) to everyone, so one signature calculation would suffice
for all.  Only the envelope addresses differ per recipient.

The place where body-hash provides a performance advantage applies is
when the same body is sent multiple times but the signed header fields
(most commonly To:) are customized for the recipient.  I get some
newsletters like that, too (although not all of them that look the same
actually are the same because embedded links often have per-user
tracking features added).  Another approach for that is to not sign the
To: address, but I'm not sure that's a really good idea, since an
attacker could then replay a signed message to me with:
    To: "Insert objectionable spam here" <[email-masked]>

The extent to which this optimization actually helps is open for
debate.  As Hector points out in a subsequent message, I notice that
there is a trend toward more per-recipient customization of messages, in
order to better personalize them, in addition to the customization of
link addresses I mentioned above.

-Jim

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 24 Mar 2006 10:09:13 -0500

----- Original Message -----
From: "Jim Fenton" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 24, 2006 8:54 AM
Subject: Re: [ietf-dkim] 1193 considered harmful

> link addresses I mentioned above.

Right.

But I think it is an important question because it can defined a new level
of software change requirements too.

Case in point,  if a software change proves to be too difficult or not
feasible, one can opt or skip a particular method or model over another.
Will Dave [or anyone in general] every change his list server software just
to support DKIM?  What incentive does he has to do so?

Anyway, lets look the benefits. Let me see if I understand the proposal
again:

Signer:

  1) Hash Body
  2) Add Body Hash result to Header (example only: bodyhash=)
  3) Hash Headers and Sign (b=)

In my view, this will offer tremendous benefits for the verifier:

  1) Clear optimization and scalability benefits,

  2) Allows verification to be perform on message headers,

  3) Integrity Issues clearly separated allowing for
     higher degree of confidence in determining failure,

  4) Increases reliability of the protocol,

  5) Reduces many of the MAILING LIST issues,

  6) Addressing key critical issues or concerns that hamper all
     PAYLOAD based protocols.

The way the industry is header, #6 is very important to the extent that I
have been working on a new ESMTP I-D proposal that I believe will be begin
help prepare future systems address such PAYLOAD based protocols.   This
1193 BodyHash proposal will fit exactly with what I expecting in my
proposal:

http://isdg.net/public/ietf/drafts/draft-santos-smtphead-00.html

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 24 Mar 2006 11:43:23 -0600

> header fields) to everyone,

I don't understand because my copy has "TO: [email-masked]" in 
the headers.  Why would the list send a message to you with my address 
in the TO: header?  Doesn't your TO: header have your address in it?

Sorry, I'm missing something fundamental here I suspect.

-- 
Arvel

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 24 Mar 2006 10:31:44 -0800 (PST)

On Fri, 24 Mar 2006, Arvel Hathcock wrote:

> I don't understand because my copy has "TO: [email-masked]" in the 
> headers.  Why would the list send a message to you with my address in the TO: 
> header?  Doesn't your TO: header have your address in it?
>

Different mail lists operate in different ways. Some will have "To" set
to mail list even after mail list processing, otherwise do it so that
each recipient email address is put in "To:" and mail list address is
in CC or Reply-To. Unlike what some here claimed, most mail lists now
(at least true mail lists that use special software and not just
forwarders set with multiple recipient and static configuration) do 
add unique per-recipient header fields including To and as Hector noted 
there is a trend towards even greater personalization including in email 
body (but this is still very rare and I don't think it'll catch up as its 
not useful for majority of mail list activity).

So to summarize for majority of true mail lists it is in fact true
that mail content body is the same and header is different and as
such mail lists would save on processing if hash of email content
body is available and can be reused.

---

From: Jim Fenton <[email-masked]>
Date: Fri, 24 Mar 2006 10:56:21 -0800

Arvel Hathcock wrote:
> I don't understand because my copy has "TO: [email-masked]"
> in the headers.  Why would the list send a message to you with my
> address in the TO: header?  Doesn't your TO: header have your address
> in it?
That happened because I did a "reply all" on your message, my MUA
populated the To: header field with your address and the CC: header
field with the list address.  Everybody got a message that said To:
[email-masked]

Just to show that, I changed the To: address on this message to myself. 
You should see that too.

-Jim

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 24 Mar 2006 13:09:06 -0600

> field with the list address.  Everybody got a message that said To:

Thanks!  Sorry if I wasted anyone's time.

-- 
Arvel

---

From: Barry Leiba <[email-masked]>
Date: Fri, 24 Mar 2006 18:54:53 -0500

I have a suggestion that I think might (ha!) satisfy everyone.  That is, 
I THINK it will satisfy those who want the separate body hash, it will 
address Mike's compatibility concern, and it will not give Mark hives 
because of overloaded tags and burgeoning combinatorics.

Suppose the base doc said this sort of thing:

---------------------------------------------------------
... signers MUST use a=rsa-sha256 ...
... hash the body and put the hash value in bh= ...
... hash the headers, sign that hash, put the signature into b= ...
... etc, etc, etc ...

Section x.y: Backward compatibility with the pre-standard version

Earlier, pre-standard implementations of DKIM used a different hash 
mechanism.  Owing to significant deployment of that mechanism for early 
adoption and experimentation/refinement leading to this specification, 
current implementations SHOULD maintain signature-verification 
compatibility with the earlier version as follows:

1. Support the SHA-1 hash algorithm, and recognize and respect the 
a=rsa-sha1 tag.

2. Support the earlier mechanism of using a single hash, as indicated by 
the absence of bh=, by computing the message hash thus:  <describe how 
to put the headers and body together for the hash here, noting that the 
canonicalization is identical>

Verifiers MUST NOT accept a=rsa-sha1 in the presence of bh=, and MUST 
NOT accept the absence of bh= in the presence of a=rsa-SHA256; those 
combinations are contrary to this specification, and their use is 
NON-COMPLIANT.
---------------------------------------------------------

What do y'all think (I picked that up in Dallas)?

Barry

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 25 Mar 2006 03:30:06 -0500

Barry,

At first I thought your backward compatibility (BC) proposal would be a
compromise but I changed my mind based on proven history where  BC
considerations caused more harm and got us to the point we are today.

If DKIM was a standard today and widely adopted, I can understand the BC
concern.  The fact is, it is not a standard, a protocol still in flux and it
is not, by far, widely adopted.  Not even close.  It is still extremely
isolated and today, I can not in good conscious, help promote or support a
new protocol for implementation that is,.... well.... half-baked!"

In any case,  if BC is to be considered, here is my input:

    1) Signing requirement, and
    2) Migration.

1) Signing requirement.

I don't see the tie-in between the ALG and the BodyHash proposal.  I see
this as an independent issue.   Even though I think we need to encourage
SHA256, I still see it as an viable option to use a lower footprint SHA1.
There are many possibilities where we don't need the higher strength.

2) Migration

This isn't like SMTP where we had nearly 10-12 years (1982 to 1994) of HELO
only transactions before EHLO was invented and we had no choice and it made
sense to support both HELO and EHLO.

Once the standard is official and DKIM is shown to be a feasible
consideration,  I find it hard to believe that early adopters, who indeed
took it upon themselves to adopt DKIM early for whatever reasons, marketing
or experimentation,  and in fact were a major participants of its
development, if not the key cogs and inventors,  will not bother to
support/upgrade to official standard adaptation.

I believe most systems will follow the official standard first and raise
eyebrows about supporting those early adoptions that might be weaker than
the official standard.

In fact, if this is proven to be the case,  as history has proven already
with SMTP, we open up a threat entry point where bad actors will not bother
to support the "official standard" because there would be a "early version
loophole."  That's the problem with have today with SMTP compliance -
atleast 80% are not compliant forcing us to add new layers of security.

Unlike the 821 to 2821 transition era,  would it be possible to have a
"Migration" concept this time around?

Suggestions only:

A section specific to  Early Adopters:

     Section x.y:

      Early adopters are HIGHLY encouraged to migrate to the official
      standard as soon as possible.  See  section x.y+1

A section specific for  Verifiers supporting Early Adopters:

     Section x.y+1

     Verifiers ARE NOT required to support early adopters over a extended
period,
     especially if it is deemed harmful to support early adopters.  A
migration period
     of XYZ months may be considered.  SMTP-level  DKIM implementations
     MAY issue a 55x "DKIM Version Not Supported"  response..... etc.

In any case, maybe none of the above would be necessary because I just find
it hard to comprehend that the early DKIM adopters investing in DKIM today
are just going to STOP and not use the official standard.  I find that a
very strange though that vendors will invest R&D time and resources for
something "experimental" in nature today and don't plan to further change it
when the official specs are released.   Why should the majority of the world
be compromise because of the premature early adoption decision to add a
non-standard DKIM unfinished protocol into production products?  If it is
shown that non-standard DKIM is weaker than standard-DKIM,  can anyone
explain to me why BAD actors will avoid the non-standard version?

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 25 Mar 2006 08:35:07 -0800

At 6:54 PM -0500 3/24/06, Barry Leiba wrote:
>. . .

This is a *very* bad idea. SHA-256 has been around for a relatively 
short period of time. It has different block sizes than the other 
hashes that have been analyzed over the past decade, it uses 
different types of rounds, and so on.  Mandating a single algorithm 
that is new and fairly untested (even though it seems bigger and 
stronger) is very, very risky.

We should stick with the wording agreed to in the f2f meeting (after 
getting consensus on the list), namely:

At 1:10 PM -0800 3/20/06, Hallam-Baker, Phillip wrote:
>Receivers MUST implement SHA-1 and SHA-256
>Signers MUST implement SHA-256
>Signers SHOULD use SHA-256

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 25 Mar 2006 08:41:41 -0800

At 6:54 PM -0500 3/24/06, Barry Leiba wrote:
>mechanism.  Owing to significant deployment of that mechanism for 
>early adoption and experimentation/refinement leading to this 
>specification, current implementations SHOULD maintain 
>signature-verification compatibility with the earlier version as 
>follows:
>

Yes.

>2. Support the earlier mechanism of using a single hash, as 
>indicated by the absence of bh=, by computing the message hash thus: 
><describe how to put the headers and body together for the hash 
>here, noting that the canonicalization is identical>

Proposal: instead of basing this on the absence of the "bh=" header, 
we really should just start using v=. They would have the identical 
semantics in this case, and would be more flexible for the future. 
That is, "Support the earlier mechanism of using a single hash, as 
indicated by the absence of v=". We would start using "v=" in the -01 
draft, maybe with a value of "-01" (although the value is truly 
unimportant as long as it changes with each technical or semantic 
change we make).

If people like this idea, I will propose concrete changes to the -00 
text to make v= required for implementations starting with -01, 
optional to include, and its absence means the protocol and semantics 
pre-IETF version of the document.

>Verifiers MUST NOT accept a=rsa-sha1 in the presence of bh=, and 
>MUST NOT accept the absence of bh= in the presence of a=rsa-SHA256; 
>those combinations are contrary to this specification, and their use 
>is NON-COMPLIANT.

Fully disagree. A few folks on this list have already said that they 
can do both, and the pre-IETF versions certainly did not prohibit the 
use of SHA-256.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Sat, 25 Mar 2006 11:24:19 -0800

Barry Leiba wrote:

> I have a suggestion that I think might (ha!) satisfy everyone.  That 
> is, I THINK it will satisfy those who want the separate body hash, it 
> will address Mike's compatibility concern, and it will not give Mark 
> hives because of overloaded tags and burgeoning combinatorics.
>
> signature-verification compatibility with the earlier version as follows:
>
> 2. Support the earlier mechanism of using a single hash, as indicated 
> by the absence of bh=, by computing the message hash thus:  <describe 
> how to put the headers and body together for the hash here, noting 
> that the canonicalization is identical>
>

---

From: Michael Thomas <[email-masked]>
Date: Sat, 25 Mar 2006 11:26:17 -0800

Ooops, sorry about that last send.

> hives because of overloaded tags and burgeoning combinatorics.

How does this address my concern? This looks like my current receiver
would fail with the new signature format. That's not backward compatable.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Sat, 25 Mar 2006 12:14:54 -0800

Barry Leiba wrote:

> All verifiers already have to change, to support SHA-256.

But that still doesn't address my concern. It's not backward compatible.

It would be nice if the proponents of this change addressed my other
concerns that this proposal doesn't actually deliver what they think it's
delivering.

       Mike

---

From: Barry Leiba <[email-masked]>
Date: Sat, 25 Mar 2006 14:57:29 -0500

Barry

---

From: Dave Crocker <[email-masked]>
Date: Sun, 26 Mar 2006 09:50:20 -0800

> All verifiers already have to change, to support SHA-256.

Sounds like this is another exchange talking past each others' meanings.  At the
least, I am increasingly confused by which concern people are responding to.

So:

1) Yes, an IETF DKIM verifier must be different from a pre-IETF verifier.
However we have so far preserved the ability of a pre-IETF signer to work with a
post-IETF DKIM verifier. (So, Barry's statement is true, but I'm not sure it
addressed the concern.  Or am I, yet again, missing the point?_

2) When we talk about compatibility, could we start using some sort of notation,
to make very clear what type and direction we have in mind.  For example, I
believe the over-the-wire concierns divide beteen::

   a) pre-IETF DKIM -> post-IETF DKIM compatibility (pre2post)

   b) post-IETF DKIM -> pre-IETF DKIM compatibility (post2pre)

So far, we have preserved pre2post compatibility but do not have post2pre.

d/
-- 

Dave Crocker

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 26 Mar 2006 14:38:18 -0500

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, March 26, 2006 12:50 PM
Subject: Re: [ietf-dkim] 1193 considered harmful

> to make very clear what type and direction we have in mind.

Dave,

DKIM is not a standard.  It is a proposal in flux!

It is not widely adopted.   It is not an infrastructure.   It is not a
factor by any means that should suggest that  an on-going half-baked, and in
my view, somewhat harmful, proposal to be pushed down the networks throat.
I find it incredibly fascinating how anyone might believe everyone (THE
WORLD) will accept this protocol as is.   Didn't MARID mean anything?

> For example, I

Why not use real acronyms? such as STD vs. NON-STD.  This tends to tell the
real story.   If both were standards, widely adopted ideas, then I believe
you would find more agreement.  But it is not  a standard, It isn't widely
adopted.

  - STD DKIM MUST support STD DKIM systems
  - STD DKIM MAY support NON-STD DKIM systems
  - NON-STD DKIM will only understand NON-STD DKIM systems.

But what I don't understand is:

  - NON-STD DKIM will NOT support STD DKIM systems.

   Why would Early Adopters of a non-standard proposal NOT
   upgrade to support  the standard proposal?

Really,  do you really believe we have such a large, widely adopted "DKIM
infrastructure" at this  point based on a NON-STD DKIM proposal in flux that
it would have a detrimental effect on the network once a better STD DKIM
emerges?

I don't think anyone can answer YES to that with a straight face.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 26 Mar 2006 17:32:48 -0500

> However we have so far preserved the ability of a pre-IETF signer to 
> work with a post-IETF DKIM verifier. (So, Barry's statement is true,
 > but I'm not sure it addressed the concern.

I believe my text, or a reasonable variant of it (modulo Paul's 
concerns, for instance) preserves this ability.  Do you disagree? 
Perhaps, if you do, changing a SHOULD to a MUST would fix that?

Barry

---

From: Michael Thomas <[email-masked]>
Date: Sun, 26 Mar 2006 16:45:47 -0800

> Perhaps, if you do, changing a SHOULD to a MUST would fix that?

This has never been in dispute. It's not backward compatible for the
receiver and that has *always* been my concern. That and the new
proposal doesn't do many of the things that its proposers claim. I'm still
waiting for the proposers to tell me why I'm wrong.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Sun, 26 Mar 2006 16:52:00 -0800

> least, I am increasingly confused by which concern people are 

Indeed. I'm not a priori against changes. I'm against changes for the sake
of changes, especially in areas of the spec that are time proven problematic
areas for interoperability. I want the bar to make backward incompatible
changes high insofar as the proposers need to *justify* why it's worth
causing churn. It's not good enough to just say "well, we're making other
incompatible changes, therefore, it's dueces wild". Both the 
canonicalization
and hash problems rise to that standard. The proposers of this change have
not made the case.

       Mike

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 27 Mar 2006 04:39:47 -0500

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

> receiver and that has *always* been my concern.

But Mike, isn't it already non-backward compatible when "relaxed" was added
within the last few months?  Did you have a concern then  or was Relaxed a
required new feature?

In my opinion this bodyhash proposal has major set of more benefits for the
receiver than this single idea this relaxed change addressed.  Relaxed only
addressed, I believe, a security concern.   The bodyhash address all sorts
of real issues that will happen on a every day basis across the board such
as error detection and overhead reduction and optimization.  Yet, it was
deem necessary to break all the imaginary widely adopted systems out there
using the older original DKIM spec.  I could be wrong, but I don't even
remember it (relaxed)  even being discussed in the list  - the change just
appeared out of thin air when the current proposal was released.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Mar 2006 11:45:13 +0100

Michael Thomas wrote:
>  That and the new

I think that a number of those in favour have stated their
reasoning, as have you. So I don't think there's a lot that
remains to be said in this particular debate. But if I've
missed something that you reckon still needs a response (quite
possible) then send me a link to the archive.

Right now, I guess most folks have had their say, and Barry
and I, as chairs, will just have to make the call at the
appropriate time (when the minutes are final).

Stephen.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 27 Mar 2006 08:23:12 -0800

> possible) then send me a link to the archive.

Yes,  here's the message I sent out last week which I haven't
heard a reply from the proposers of this change:

Barry Leiba wrote:

> store a body hash there?  It seems to me that the combination of a 
> BODY hash and z= will give the best diagnostic combination.  l= seems 
> a red herring (but explain, if I'm wrong), since the signer and 
> verifier must already deal with deciding which part of the body 
> contributes to the hash, whether they then hash it separately or not.
>
> body hash.  For one, it means that the verifier can start validating 
> the sig after having read the header-terminating CRLF, without yet 
> having to read the body, thus allowing the signature validation to be 
> done in parallel with the reading of the body (which may be 
> significant with large bodies). 

I replied:

1) ± can determine if body or headers are broken; - because it can

        Mike

1) ± can determine if body or headers are broken; - because it can

        Mike

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Mar 2006 17:33:09 +0100

> heard a reply from the proposers of this change:

Actually, I thought there'd been a couple of responses to
that, in any case some did discuss some of the issues you
list even if no-one so far has given a blow-by-blow
response.

I believe I haven't seen a response to your point that verifiers
will still be waiting for the key and may have hashed the entire
body before the key arrives (I assume the response will be the
obvious "caching" and "signer benefits" points;-)

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 27 Mar 2006 09:51:27 -0800

On Mar 27, 2006, at 8:33 AM, Stephen Farrell wrote:
>>> remains to be said in this particular debate. But if I've missed  
>>> something that you reckon still needs a response (quite possible)  
>>> then send me a link to the archive.
>>
> Actually, I thought there'd been a couple of responses to that, in  
> any case some did discuss some of the issues you list even if no- 
> one so far has given a blow-by-blow response.

There has been an attempt.
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002823.html

> obvious "caching" and "signer benefits" points;-)

When a message includes many signatures, fetching keys in parallel  
can be mitigated by checking the body hash contained within the  
signature header.  Without this hash parameter, the value of each of  
the multiple signatures to the message is not apparent.  The lack of  
a hash requires individual signature verification to ascertain  
whether the signature is still of value.

A signature could be added by a mailing list after flattening the  
message.  With the hash of the body included in the header, checking  
which signature includes a valid hash can exclude DNS transactions  
for already broken signatures.  When several signatures include the  
same hash value, but incorporate different headers, the value of the  
signature clearly relates to the information added to the message via  
additional headers.  With a potential for network amplification,  
fetching keys for all signatures within a message is perilous.  The  
hash of the message body within the signature enables a means to  
better prioritize which signatures are checked.

-Doug

---

From: Barry Leiba <[email-masked]>
Date: Mon, 27 Mar 2006 22:50:16 -0500

> absent other upsides I've missed, I really don't see the overall

When Mike posted this the first time, I thought he made a couple of good 
new points with items 2 and 5.  I decided to leave my "chair" hat on and 
see where we went with those, and I don't think they've been adequately 
responded to so far.  Comments addressing those are cetainly new input, 
and are welcome.

I do think we can write the spec so that the proposed change doesn't 
break old signers with new verifiers.  I think that's the side of 
compatibility that's most important.

I think we cannot make old verifiers work with new signers in any case, 
if we encourage new signers to move to SHA-256 (unless the signers 
double-sign).

I think Mike's still right that the advantage in item 2 is weakened by 
the fact that we still have to retrieve the key, and we might as well 
continue sucking down the message body while that happens.

---------------------------------

Back to "chair" hat again:
I agree with Stephen that we need to finish up this issue.  I've seen a 
few posts supporting the change, so I'd like to ask specifically if 
anyone besides Mike thinks that we should NOT change the spec to hash 
the body separately as discussed.

If you have not yet said that you support the change, please post here 
and say that you DO support the change, that you DO NOT support the 
change, or that you DON'T CARE.  Further discussion is also fine if 
there's something NEW to add, but please don't rehash what's already 
been said.  The key point is, as Mike makes clear, whether the 
advantages of this are worth the incompatibility that it causes.

I plan to get minutes posted tomorrow, and we'll have a comment period 
on the minutes, including this issue.

Barry

---

From: Tony Hansen <[email-masked]>
Date: Mon, 27 Mar 2006 23:03:24 -0500

I can live either way; I'll be changing my code to match whatever the
decision is.

	Tony Hansen
	[email-masked]

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 28 Mar 2006 02:16:12 -0500

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

> change, or that you DON'T CARE.

In case it was not recorded,  I think the BodyHash 1193 concept will be a
significant improvement to DKIM and thus I support it be added to the DKIM
base proposal.

> The key point is, as Mike makes clear, whether the

We already have a compatibility problem Barry, with last months introduction
of the
"relaxed" canocalization method to this still unstable proposal.    It broke
all older verifiers.  Everyone had to change their codes to support it.

We will definitely have a more greater set of benefits with this bodyhash
proposal.  I see no negatives whatsoever thus I didn't agree with Mikes
plus/minus itemized list.