Subject: [ietf-dkim] Relaxed body canonicalization

From: Paul Hoffman <[email-masked]>
Date: Mon, 26 Jun 2006 10:06:29 -0700

Greetings again. Issue 1295 ("issue with relaxed body 
canonicalization?") was discussed on the Jabber chat last Thursday. I 
was not able to attend the chat. The resolution came out as:

Brief discussion on whether to leave it in for now, consensus is to 
leave it and remove later (maybe at move to Draft Std) if it turns 
out to be unused.
1295: CLOSE, no change.

The transcript, from 
<http://www.ietf.org/meetings/ietf-logs/dkim/2006-06-22.html>, is:

>[11:42:35] <Barry Leiba> 1295: issue with relaxed body canonicalization?
>[11:42:51] <Barry Leiba> I think we decided that Sendmail will fix 
>this, and we won't change DKIM for it. Right?
>[11:43:04] <thomasm> I don't think so
>[11:43:07] <eric> i feel strongly about keeping relaxed header, but 
>i'm neutral on relaxed body.
>[11:43:09] <Barry Leiba> Oops, wrong one.
>[11:43:15] <Barry Leiba> I was thinking about header.
>[11:43:16] <eric> there's no sendmail issue with relaxed body.
>[11:43:19] <Barry Leiba> For body.....
>[11:43:39] <eric> the main reason i can see to keep it is symmetry 
>with the header.
>[11:43:42] <thomasm> I'm sort of weakly in favor of keeping it
>[11:43:51] <sm-msk> what he said
>[11:43:58] <sm-msk> what both said actually
>[11:43:59] <eric> deleting it would simplify the code, but not by much.
>[11:44:07] <thomasm> I'd sort of like to keep options open, though 
>with no good empirical reason
>[11:44:10] <Barry Leiba> As I see it, we can keep relaxed body for 
>now, and toss it in revision (like when we move to Draft Std) if 
>it's not used.
>[11:44:12] <sm-msk> and maybe some rewriter we haven't anticipated yet
>[11:44:13] <eric> so I'm +0.1 for keeping it.
>[11:44:28] <thomasm> +1 Barry
>[11:44:35] <Barry Leiba> Does anyone REALLY want to toss it now?
>[11:44:38] <sm-msk> i'm a little stronger for that, let's say +(2/3)
>[11:45:02] <Barry Leiba> 1295: CLOSE, no change.
>[11:45:08] <thomasm> I got the feeling that would have been Paul's preference

The last comment was definitely wrong (assuming that I'm the "Paul" 
being referred to): I definitely think relaxed body canonicalization 
should be removed from the -base spec unless there is a known use 
case.

Removing the definition of relaxed body canonicalization would 
simplify the base spec. It would also make one less thing for 
implementers to test; this is particularly poignant because no one 
seems to want to use it, so we won't have good test cases.

If we remove the definition of relaxed body canonicalization, and a 
use case comes up later, someone can write an extension document 
defining it (and, hopefully, include examples). The "c=" tag would 
still allow body canonicalization, so an extension doesn't involve a 
new tag.

Absent a use case that the WG agrees on, we should take this one out.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Mon, 26 Jun 2006 10:20:49 -0700

Paul Hoffman wrote:

> leave it and remove later (maybe at move to Draft Std) if it turns out 
> to be unused.
> 1295: CLOSE, no change.
>
> The transcript, from 
>> now, and toss it in revision (like when we move to Draft Std) if it's 
>> not used.
> should be removed from the -base spec unless there is a known use case.

FWIW, I was replying to Barry's "Does anyone REALLY..." above.

       Mike

---

From: Barry Leiba <[email-masked]>
Date: Mon, 26 Jun 2006 14:21:15 -0400

Paul Hoffman said (abridged):
> I definitely think relaxed body canonicalization 

As we can see from the jabber-log excerpt, there are three opinions to 
keep "relaxed body", but they're weak (Murray is the strongest, and he, 
too, is waffling).  Paul, on the other hand, is strongly in favour of 
dropping it.

The decision from the jabber meeting was to keep it, thinking that we 
could drop it later if it turns out not to be used.  Paul correctly 
points out that we could just as well drop it, and put it in later if it 
turns out to be needed.

I'd like to see other participants weigh in; please do not remain silent 
and assume anything about what Stephen and I will take that to mean. 
I'd especially like Eric, Murray, and Mike to say whether they're swayed 
by what Paul said.

For what it's worth, I agree with Paul.  If those who've been running 
this stuff haven't found a real need for "relaxed body", why don't we 
fall on the side of simplification?

Barry

--
Barry Leiba, Internet Messaging 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: Michael Thomas <[email-masked]>
Date: Mon, 26 Jun 2006 11:40:06 -0700

> seems to want to use it, so we won't have good test cases.

I wouldn't say that for us it's not that we don't want to use it, but that
we haven't gotten around to using it. Right now, we have a pretty good
baseline of what simple/body does. I've been wanting to run an experiment
to see what happens if relaxed is enabled. Which is why I'm generally of 
the mindset
that leaving it in will give us the ability to use real data to inform a 
later
decision at DS. Removing it now, we'll never know.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 26 Jun 2006 11:41:09 -0700

I'd still like it left in and if it's unused or providing no value, to 
remove it
at DS.

       Mike

Barry Leiba wrote:

>> I definitely think relaxed body canonicalization should be removed 
>> from the -base spec unless there is a known use case.
>
>
> keep "relaxed body", but they're weak (Murray is the strongest, and 
> he, too, is waffling).  Paul, on the other hand, is strongly in favour 
> of dropping it.
>
> points out that we could just as well drop it, and put it in later if 
> it turns out to be needed.
>
> I'd like to see other participants weigh in; please do not remain 
> silent and assume anything about what Stephen and I will take that to 
> mean. I'd especially like Eric, Murray, and Mike to say whether 
> they're swayed by what Paul said.
>

---

From: John Levine <[email-masked]>
Date: 27 Jun 2006 09:57:04 -0000

I'm with Paul, the more marginal features we can remove, the more
likely people are to implement our spec correctly.

R's,
John

---

From: Jon Callas <[email-masked]>
Date: Tue, 27 Jun 2006 03:28:59 -0700

On 26 Jun 2006, at 11:41 AM, Michael Thomas wrote:

> I'd still like it left in and if it's unused or providing no value,  
> to remove it
> at DS.
>

I agree with Mike. There's plenty of time to drop it. If we get  
closer to DS and experience is showing we don't need it, it's easy to  
drop it. It is very difficult to put it back in again if we drop it  
now and regret that decision.

	Jon

---

From: Dave Crocker <[email-masked]>
Date: Tue, 27 Jun 2006 13:37:06 +0200

> points out that we could just as well drop it, and put it in later if it

I had debated whether to make the following point, upon reading the jabber log,
so I'm happy it came up on its own:

The decision to retain the feature seems to come from the view that the current
cost of keeping it will be low and the cost of removing later will be low.

I believe both assessments are incorrect.

Keeping a questionable feature carries a significant cost:  Each feature is an
incremental barrier to adoption, both in terms of development
effort and in terms of testing and certification effort. Worse, the aggregate
effect of a set of features seems to have a non-linear impact, so the increments
-- after the first few features -- are not small.

In reality, it is far easier to later add features that are later deemed
required, than it is to later drop features that are initially deemed questionable.

(This, of course, is all in the classic spirit of good system design that looks
for what can be removed, rather than what can be added.)

d/
-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Tue, 27 Jun 2006 13:43:11 +0200

Keeping a questionable feature carries a significant cost, without the attendant
benefit that one would like:

     Each feature serves as an incremental barrier to adoption, both in terms of
development effort and in terms of testing and certification effort.  Worse,
after the first few features, each additional feature's incremental cost is
larger than the one before.  In other words the aggregate cost seems to be
something like exponential, combinatorial or the like.

In other words:  If we do not have a strong consensus that a feature is required
for the initial release of DKIM, we really ought to drop it.

d/
-- 

  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 27 Jun 2006 13:43:42 +0200

Keeping a questionable feature carries a significant cost:  Each feature serves
as an incremental barrier to adoption, both in terms of development effort and
in terms of testing and certification effort.  Worse, after the first few
features, the increments increase.  In other words the aggregate cost seems to
be something like exponential.

It is far easier to later add new features that are later deemed required, than
it is to later drop features that are initially deemed questionable.

d/
-- 

  Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Tue, 27 Jun 2006 13:56:07 +0200

On Jun 27, 2006, at 12:28 PM, Jon Callas wrote:

>> I'd still like it left in and if it's unused or providing no  
>> value, to remove it
>> at DS.
>>
>
> closer to DS and experience is showing we don't need it, it's easy  
> to drop it. It is very difficult to put it back in again if we drop  
> it now and regret that decision.

I also agree with Mike's view.  It would be unfortunate to find some  
gateway or MTA is not accommodated which represents some percentage  
of users.  Until testing is more complete, the minor change afforded  
by the relaxed body canonicalization may represent something  
statistically significant.  If not, it should be removed.  Having  
information makes this choice an easier call, where removing this  
option now will negate an ability to collect information that  
isolates the problem.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 27 Jun 2006 13:35:45 +0200

> likely people are to implement our spec correctly.

+1

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Jun 2006 13:14:20 +0100

Just two thoughts on this issue, that I've not seen raised so far.
Dunno if they'll change anyone's positions.

1. Some people wouldn't see an important distinction between PS and DS
since more-or-less everyone has to implement the PS and few features,
once deployed, are totally deprecated. That might influence whether or
not you think its useful to remove it now or at DS. OTOH, if everyone
has to support simple regardless of PS vs. DS, then who cares? There's
no effect on interop.

2. There must be some probability that another body c14n scheme will
turn out to be more useful (e.g. the s/mime or pgp scheme). If so,
would it be good or bad to have relaxed in the PS RFC? Depends on your
guess as to the probabilities I suppose.

Regards,
Stephen.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 27 Jun 2006 14:24:16 +0200

> has to support simple regardless of PS vs. DS, then who cares? There's

In addition, DS has become meaningless.

Very few of standard-track documents ever go beyond PS.

d/

-- 

  Dave Crocker

---

From: Jon Callas <[email-masked]>
Date: Tue, 27 Jun 2006 06:44:27 -0700

> Very few of standard-track documents ever go beyond PS.

Okay, so let me correct the specific data point of DS. We could delay  
to WG last call. A year ago, I would have thought that we'd never be  
able to drop a canonicalization like relaxed. It looks like that was  
pessimistic. I just don't think the time is now to drop it. If we  
agreed now to revisit during last call whether it was to stay or go,  
I'd be happy.

	Jon

---

From: Mark Delany <[email-masked]>
Date: Tue, 27 Jun 2006 15:08:19 +0000

> likely people are to implement our spec correctly.

I too am a big fan of removing marginal functionality from the core.

Given that over the last year or so no compelling cases have emerged
for *this* particular canonicalization (eg, discovery of a widely
deployed munger), it's not even clear that if we do later find a need
for another body canonicalization, that "relaxed" will satisfy that
need.

In other words, we are now in the mode of guessing that some future
need will be serendipitously solved by this functionality. Could it
not as easily be the case that this future problem needs a
canonicalization other than "relaxed"?

As I recall, all of the canonicalizations were based on conjecture
about what happens to mail in transit. Certainly conjecture by
experienced folk, nonetheless, our question now should be: was that
conjecture correct?

One other point. If we assume wide-spread adoption, the requirement
for canonicalization should diminish over time as MTA programmers
internalize that mail munging is bad. Conversely, if there is no
wide-spread adoption, we're unlikely to discover this future need.

Mark.

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 27 Jun 2006 11:48:55 -0500

Although we've tested with all variations our implementation defaults to 
simple and we've seen no reason to change to relaxed so far.  I'm happy 
to go either way on this debate.

-- 
Arvel

---

From: Tony Hansen <[email-masked]>
Date: Tue, 27 Jun 2006 14:52:14 -0400

nofws in domainkeys affects both headers and the body. The rules for how
it affects the header and body are similar but different. nowsp in
allman-00 was defined to be similar to domainkeys nofws. In allman-01,
nowsp was split into multiple values to cover the header and body
separately.

Why was nofws for the body defined? What are the use cases that it was
trying to prevent from happening? Has anyone using domainkeys hit any of
those cases? Is anyone who is using domainkeys also using nofws? Or are
all domainkey installations using simple?

We know that there will be problems with the use of simple for headers.
Why aren't we talking about getting rid of that? I ran numerous
cross-platform tests using c=simple for headers. I had to jump through
hoops, e.g. avoiding gateway systems, to get them to mostly pass. Some
of them still wouldn't pass because two different dkim implementations
were built on underlying library support that couldn't handle the simple
spec, (milter and qmail).

We do *not* know if there will be problems with simple for the body that
relaxed for the body would fix.

If we really wanted to simplify things, why not just get rid of c=simple
for headers as well as getting rid of c=/relaxed for the body?

	Tony Hansen
	[email-masked]

---

From: Mark Delany <[email-masked]>
Date: Tue, 27 Jun 2006 20:02:52 +0000

> all domainkey installations using simple?

Both.

> hoops, e.g. avoiding gateway systems, to get them to mostly pass.

As has been stated before, choosing a canonicalization is not just a
choice of survivability, it's also a security choice. It's been made
very clear to us that some senders prefer simple over relaxed because
they prefer the security trade-off over the survivability trade-off.

Mark.

---

From: John Levine <[email-masked]>
Date: 28 Jun 2006 16:01:42 -0000

>for headers as well as getting rid of c=/relaxed for the body?

Sounds good to me. Eliot?

R's,
John