Subject: Re: WG Review: Domain Keys Identified Mail (dkim)

From: Ted Hardie <[email-masked]>
Date: Tue, 20 Dec 2005 14:23:18 -0800

I believe the text here:

>
>Since experimentation resulted in significant Internet deployment of these
>specifications, the DKIM working group will make every reasonable attempt to
>keep changes compatible with what is deployed, making incompatible changes only
>when they are necessary for the success of the specifications.

implies the need to be clarify the charter in two ways.  The charter needs to reaffirm that the IETF has change control over the specifications at this point, so that there is no question over who gets to decide whether an incompatible change is necessary.  The charter also needs to indicate that the working group will consider the relationship of this work to other, existing IETF technologies.  That does not imply that it needs to adopt them, but explaining why it chose to use, for example, this signature mechanism rather than one of the existing ones would help the IETF understand whether this mechanism is a better point solution, implies a problem with the existing mechanisms which should be fixed in the existing solutions, or should be considered as the basis of a more wholesale replacement.   Doing so in its first milestone document seems like a reasonable way to accomplish this, but doing so in the standards-track specifications also seems reasonable.

			regards,
				Ted Hardie

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Dec 2005 14:44:15 -0800

Ted,

> implies the need to be clarify the charter in two ways.  The charter
> needs to reaffirm that the IETF has change control over the

We could choose to have every charter repeat every premise for all IETF 
work.

That would be wasteful, at best.

Having this point in this charter mostly serves as a statement of 
mistrust, rather than providing any useful education or constraint.

> charter also needs to indicate that the working group will consider
> the relationship of this work to other, existing IETF technologies.

Again, a nicely open-ended and universal requirement that applies to all 
working groups.  It is therefore meaningless, except for its implicit 
threat at more overhead and undefined requirements to satisfy.

> That does not imply that it needs to adopt them, but explaining why
> it chose to use, for example, this signature mechanism rather than
> one of the existing ones would help the IETF understand whether this

If you have specific questions that you believe the wg needs to attend 
to, then they should have been stated during the very oppe, very lengthy 
(and repeated) charter development process.

Calling for the addition of a requirement that cannot be satisfied in 
any predictable fashion is entirely counter-productive, Ted.

regards,

/d
-- 

   Dave Crocker
   Brandenburg InternetWorking
   +1.408.246.8253
   dcrocker  a t ...
   WE'VE MOVED to:  www.bbiw.net

---

From: Ted Hardie <[email-masked]>
Date: Tue, 20 Dec 2005 15:22:53 -0800

At 2:44 PM -0800 12/20/05, Dave Crocker wrote:
>We could choose to have every charter repeat every premise for all IETF work.
>

It's also a principle of good engineering that you don't make unnecessary
changes to deployed code.  This working group charter sees a necessity
to repeat that position in the charter.  That's fine by me.  I think adding in
that it is the working group that decides when that necessity hits is a good idea
in that case.  That's not mistrust of anyone, it's ensuring that everyone, including
those who join *after* this long, repeated charter development process
understand how that statement in the charter fits into the rest of our
assumptions. 

Note that very similar language was in the XMPP charter (http://www.ietf.org/html.charters/OLD/xmpp-charter.html), which had a relationship
to the deployed jabber code:

>Although not encouraged, non-backwards-compatible changes to the
>basis specifications will be acceptable if the working group
>determines that the changes are required to meet the group's
>technical objectives and the group clearly documents the reasons for
>making them.

I personally believe that clarity helped the XMPP working group and the jabber community.

>Having this point in this charter mostly serves as a statement of mistrust, rather than providing any useful education or constraint.
>
>Again, a nicely open-ended and universal requirement that applies to all working groups.  It is therefore meaningless, except for its implicit threat at more overhead and undefined requirements to satisfy.

I had hoped the sentences following the one you snipped were
clear, but apparently not.  As Eric Rescorla has several times
pointed out (http://www.educatedguesswork.org/movabletype/archives/2005/07/comments_on_dra.html), the IETF has done work on message signing before,
and some of those earlier efforts (like CMS in detached signature mode) look
enough like pieces of DKIM that there is question of whether DKIM not using
them indicates that they do not work, that this message signing is
a better point solution, that this message signing mechanism would be
better over all, or none of the above. 

Again, I'm not suggesting a change in what DKIM wants to do--I'm suggesting
the WG tell the IETF what, if anything, is wrong with the bits the IETF had already
done. "Doesn't fit, here's why" would be one answer, and there are several
logical places to do it.    I think that's pretty actionable, and that it would be a
useful, timely contribution to the relevant area of Internet engineering.
				regards,
					Ted Hardie

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Dec 2005 15:49:00 -0800

Ted,

> changes to deployed code. 

But since only *some* IETF working groups begin with work that involves
deployed code and since the degree of concern for preserving that
investment varies, it *is* appropriate to have a charter make clear what
choices are made in such a matter.

(and since I have cited this point to you quite a few times, I am not
sure why you are raising it yet-again.)

At any rate, Ted, since you seek to raise a parallel example to
substantiate your proposal, perhaps you could choose one that really is
parallel?

> Note that very similar language was in the XMPP charter
> (http://www.ietf.org/html.charters/OLD/xmpp-charter.html), which had
> a relationship to the deployed jabber code:

That's nice.

Again:  Do you have specific activities that you want the working group
to coordinate with?  If you do, what specific coordinations do you seek?

> I personally believe that clarity helped the XMPP working group and.
> the jabber community.

Me too.

But what does that have to do with your request for generic language
calling for generic coordination?

> better over all, or none of the above. 

Two reactions:

1. As interesting as such a discussion might be, it has no effect on the
technical work. The choices made were the choices made. The goal is to
make as few new ones as we can, not to spent time reviewing past
choices. If you are calling for considering changing them, then you need 
to state what kinds of changes you are seeking. For that matter, if you 
want to re-visit those choices, then you have had something like 5 
months to do that. Why must the working group be burdened with this 
overhead, since it has no utility for turning out a useful spec.

2. Excellent.  Clearly you have specific questions you want answered and
you want them in the charter.  Please state them.

And, by the way,  I seem to recall that they *were* raised and discussed
in the extended and repeated open-discussion of the charter over the 5
months it has taken to get this far.  What is it about that extended,
prior charter development that you find inadequate?

> Again, I'm not suggesting a change in what DKIM wants to do

Then the draft charter text does not need changing.

-I'm suggesting
> done. 

Earth to Ted:  THAT'S NOT THE JOB OF THIS WORKING GROUP.

As has been discussed a number of times, the issue is an interesting
topic and well worth exploring.  But it is not appropriate to task this
specification effort with that analysis task. (And by the way, I thought 
this point was settled during the Vancouver IETF.)

d/

-- 

  Dave Crocker

---

From: Ted Hardie <[email-masked]>
Date: Tue, 20 Dec 2005 16:45:06 -0800

At 3:49 PM -0800 12/20/05, Dave Crocker wrote:
>technical work. The choices made were the choices made.

It has an effect on the technical work of the IETF, by creating a new mechanism
in this space.  Describing what it makes it better/different/more appropriate helps
those who will interpret or re-use these pieces understand why they might choose
to re-use them or avoid doing so.  Saying "this is a point solution" or "this is a replacement for $FOO, and here's why we chose to replace it" is relevant to the
people who will read and use the specifications.  It's relevant to the IETF, in other
words, as well as a broader community.

			regards,
				Ted Hardie

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Dec 2005 17:16:30 -0800

Ted.

> in this space.

1. Not really.

2. This has been discussed to death, over the last 5 months.  Is there 
something about it that you did not understand?

3. What effect is it going to have on other IETF technical work?  Again, 
Ted, it sure would be helpful for you to cite specifics rather than 
abstractions, since it is specifics that the IETF delivers.

> Describing what it makes it better/different/more appropriate helps
> to re-use them or avoid doing so. 

Ahh.  So you would like every new effort to produce a document that 
records every detail of a group's decision process?   Well, yes, that 
would certainly be a good disincentive for ever trying to get work done 
in the IETF.  A working group would be assured of spending all of its 
time trying to satisfy these abstract debates -- and never knowing 
whether it would succeed -- rather than getting to deliver technical 
specifications.

Oh, that's what we already seem to be, these days.

Oh, you don't want it for *all* new efforts, just those doing anything 
that in any way relates to prior work?

Hmmm.  Actually, that's most IETF work.

> Saying "this is a point solution" or "this is a replacement for $FOO,
> and here's why we chose to replace it" is relevant to the

The nature and purpose of DKIM is stated in the DKIM spec.  It says 
neither of the things you have stated.

So we are now wandering around in territory that appears to have nothing 
to do with DKIM.

> people who will read and use the specifications. It's relevant to the
> IETF, in other words, as well as a broader community.>

It's probably more relevant to the IETF community to show that we can 
get useful work done in a timely manner.

Your re-raising old topics and arguing for conceptual discussion seems 
rather counter-productive to that end.

regards,

d/
-- 

  Dave Crocker

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Dec 2005 17:47:54 -0800

At 2:44 PM -0800 12/20/05, Dave Crocker wrote:
>>The charter

Fully disagree. There is plenty of recent evidence that WGs that are 
formed around "charged" issues attract lots of active interest from 
people who do not understand the IETF rules. We certainly saw this in 
the Atompub WG, and it seems likely that you will see it in any WG 
relating to spam. Adding this type of wording to charters of WGs 
which come with existing protocols helps set the expectations of the 
participants and therefore could help the WG act more gracefully.

Adding such a statement is all about education. It is perfectly 
reasonable to not trust that newcomers will understand IETF policy; 
heck, many folks who have been active for years don't.

>Again, a nicely open-ended and universal requirement that applies to 
>all working groups.  It is therefore meaningless, except for its 
>implicit threat at more overhead and undefined requirements to 
>satisfy.

The same reasoning above applies here. Having people whose sole 
involvement with the IETF is one new WG know that there is an 
expectation that some research will be done will hopefully reduce 
tensions during IETF Last Call and IESG review when questions like 
"why didn't you use this standards-track technology instead of 
inventing your own", or "why did you pick this standards-track 
technology over that standards-track technology", are asked.

Having these things in the charter reduces the strain on the chairs 
when the issues come up in the WG.

At 5:04 PM -0800 12/20/05, Eric Rescorla wrote:
>  > Since experimentation resulted in significant Internet deployment
>>  of these specifications, the DKIM working group will make every
>>  reasonable attempt to keep changes compatible with what is
>>  deployed, making incompatible changes only when they are necessary
>>  for the success of the specifications.
>
>As I argued on the DKIM working group list, I think this text is a bad
>idea. Part of IETF having change control of a specification is having
>the ability to make changes, and the bar of "necessary to the success of
>the specification" is way too high for that. Note that I'm not
>suggesting that the WG shouldn't consider compatibility, merely that it
>shouldn't be effectively prohibited by charter from making incompatible
>improvements.

It is fortunate that the Atompub WG didn't have language like this in 
our charter, because we made many improvements from the 
widely-deployed, pre-IETF Atom 0.3 spec. Having such language would 
have made it harder to get them in the final spec, and therefore 
would have degraded the quality of the WG's output.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Dec 2005 18:50:20 -0800

> people who do not understand the IETF rules. 
 >

1. You said you disagreed, but then provided an argument for not 
trusting participants ("people who do not understand the IETF rules".)

2. You cannot seriously think that adding the language Ted suggests -- 
he *did* suggest specific language, didn't he?  I've lost track -- will 
make any difference to the working group process.

3. Adding such language is not a remedy for bad working group management 
or participation, yet that is exactly what Ted and you seem to be 
targeting.  Since it does not target technical details of the work to be 
specified -- remember you said "education" -- that means that we now 
need to make charters bullet-proofed against an essentially infinite 
range of misunderstandings, as well as presuming that participants are 
not to be held responsible for reading basic IETF materials.  But then 
why should they be held responsible for charter contents?

>> implicit threat at more overhead and undefined requirements to satisfy.
> 

You are attempting to impose a new requirement for a charter, namely 
that it be bullet-proofed against ignorant participants.

That sounds like an interesting item to pursue in the IETF process 
enhancement discussions, because the expectation of such content in a 
charter is not specified in any current IETF process documents.

> tensions during IETF Last Call and IESG review when questions like "why 
> didn't you use this standards-track technology instead of inventing your 

1. The question has been discussed and explained at length on the 
mailing list, the two BOFs, and elsewhere, for the last year.

2. You are presuming that it is reasonable for someone to come in at the 
end of a working group and require a defense of the initial position of 
the work.  Since such a question belongs at the beginning of the process 
-- assuming that anyone has noticed that this work continues existing 
work rather than creates new work -- it is not productive to have such 
basic challenges lodged at the end of the process.

> Having these things in the charter reduces the strain on the chairs when 
> the issues come up in the WG.

What wording changes, specifically do you believe will 'reduce the 
strain on the chairs' for this particular working group?

Please provide examples of similar language having had similar benefit.

Again note that you seem to be arguing for charter language that does 
not target specific technical work but, instead, seems to have some 
other goal relating to difficult participants.  (This is as opposed to 
language that targets technical work in a way that constrains such 
difficult people.)  Remember that Ted has already acknowledged that he 
is not seeking any change in the actual technical work of the group.  He 
is, therefore, merely seeking to burden the wording group with an 
additional task that has nothing to do with the direct work at hand.

>> the ability to make changes, and the bar of "necessary to the success of

And Eric seem to keep ignoring, the question of how much change to 
target, when taking in existing technology, is an established point that 
has been experienced a number of times already.  Different choices have 
been made.  Those seeking to field DKIM have reached a consensus on 
charter language that reflect their choice for this case.  (In other 
words, Eric, rough consensus has been established on this issue.)

The impression, at this point, is that those seeking to remove all 
limits on the technical changes in fact have no interest in protecting 
the existing work.

In that light, the folks who developed DKIM would be quite seriously 
crazy to hand it over to the IETF.

>> the specification" is way too high for that.

Too high for what?  Instead of arguing principles Eric, needs to 
indicate what specific technical work that is excluded by this language 
is actually essential to the goals of DKIM.

  Note that I'm not
>> shouldn't be effectively prohibited by charter from making incompatible

And that is exactly what has been debated (and resolved) repeatedly over 
the last 5 months.

> our charter, because we made many improvements from the widely-deployed, 
> pre-IETF Atom 0.3 spec.

And presumably that was the choice of those forming the working group, 
doing the work, and/or planning to deploy the result.  In the case of 
DKIM, the decision came down in a different place.

d/
-- 

  Dave Crocker

---

From: Sam Hartman <[email-masked]>
Date: Tue, 20 Dec 2005 21:31:21 -0500

>>>>> "Dave" == Dave Crocker <[email-masked]> writes:

    Dave> If you have specific questions that you believe the wg needs
    Dave> to attend to, then they should have been stated during the
    Dave> very oppe, very lengthy (and repeated) charter development
    Dave> process.

Dave, there are two ways of reading this and if people read it
incorrectly they might come across with the impression that you were
attempting to short circuit community review.  The first way of
reading this is that it would be very nice if people with specific
concerns brought them up in the charter discussion.  That's certainly
true.  We don't want this WG review to be drawn out and we want to
move forward with WG creation.  I agree strongly with that reading.

The second is that by failing to do so, people have given up their
ability to bring forward these concerns or would not be constructive
by doing so.  While it is possible to be non-constructive at any stage
of the process, this is the first time that DKIM has formally been
before the community for review.  We had a BOF, but that was not
attended by the entire community; this WG review is the formal point
in our process where the community can bring up concerns with the
charter.

At this stage, it is appropriate to bring up concerns or to reiterate
that a concern previously brought forward has not been addressed.  In
the latter case, we solicit input from the community about whether the
concern needs to be addressed.

I realize you know all this.  I've been a bit more verbose than is
strictly necessary in the hopes of letting everyone know that we do
value their constructive input but we do require they keep that input
constructive.

Thanks,

--Sam

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Dec 2005 21:25:51 -0800

Dave Crocker <[email-masked]> wrote:
> target, when taking in existing technology, is an established point
> that has been experienced a number of times already.  Different
> choices have been made.  Those seeking to field DKIM have reached a
> consensus on charter language that reflect their choice for this case.
> (In other words, Eric, rough consensus has been established on this
> issue.)

Rough consensus inside some subgroup, not inside IETF. Indeed, that's
precisely the question that a Last Call is designed to answer.

> limits on the technical changes in fact have no interest in protecting

That may be your impression, but that doesn't mean it's the case.

> crazy to hand it over to the IETF.

I agree that if they aren't willing to cede change control
to IETF then they shouldn't hand it over, yes.

> indicate what specific technical work that is excluded by this
> language is actually essential to the goals of DKIM.

Yes, you've asserted this repeatedly. And I've repeatedly disagreed.
I don't see much point in us going over that ground again.

-Ekr

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Dec 2005 21:30:56 -0800

Sam,

> attempting to short circuit community review.  

I can't imagine how my noting that there have been two, extended rounds 
of open discussion and revision -- including two IETF BOFs -- could be 
taken as an attempting to short-circuit community review.

What I CAN imagine is that pursuing such a point will take us all that 
much farther away from chartering this group.  Please remember that this 
is a group that has been jumping through IETF start-up hoops for 5 
months already.

(By the way, I lied.  I can imagine all sorts of ways people can choose 
to misinterpret someone's statements, no matter what the person has 
actually said.)

> The first way of

Me too.

> by doing so.

But Sam, that is ultimately the way the IETF does get work done:

People who do not participate during an extended, open and productive 
process must not be allowed to come in afterwards and insist things be 
done differently.

(Please note that I already acknowledged that "it won't work" is always 
relevant, but that's not what we are dealing with here.)

   While it is possible to be non-constructive at any stage
> before the community for review.

No, Sam.  That is not correct.

DKIM has been before the IETF community for 5 months.

This is a last call event, not a first call.  It is a chartering last call.

And let me anticipate those who view it differently:  If the IETF has 
any hope of being productive in the long term, it needs to find a way to 
stop re-visiting territory that has already been worked.  What we have 
now is a process that requires constantly re-arguing topics.  There is 
really no way to make anything that looks like timely progress, if even 
one person feels like arguing against it at any point in the process.

> We had a BOF, but that was not

1.  That's not the issue here, since Ted has participated in earlier 
discussions.  He didn't like the rough consensus that was reached, so 
he's raising his concerns yet-again.

2.  The concerns raised here, so far, have nothing to do with the 
technical or functional adequacy of the proposed work.

3.  Perhaps you have heard a real "concern" expressed.  I've missed it, 
but would love to hear someone else characterize it.

     So far, the view seems to be that we are expected to a) entirely 
ignore and repeat previous work, and/or b) all the work of educating 
people who are not willing to review the public discussion archive -- 
particularly irksome when they themselves contributed to it, and/or c) 
enter into a standards process that insists on complete instability for 
those who have already invested 1-2 years creating the technology and 
services on which this effort is to be based.

     And, yes, I believe that the situation is exactly that extreme, 
which is why I am taking such a harsh tone.

     When someone bothers to do their homework and to raise a new 
question about the actual technical work, or its utility, that has not 
already received extended discussion, then they will not be wasting 
everyone's time.

(Variant:  "I don't know if this has been discussed before, but what 
about...?" presumably is a question that will be satisfied by pointing 
to the relevant place in the online archive.)

> that a concern previously brought forward has not been addressed.

Except that Ted's concerns HAVE been addressed, Sam.

> value their constructive input but we do require they keep that input

Sam, from what I've seen, you are pretty consistent about trying to find 
a productive path.  I often do not agree with your assessment of what 
that path should be, but that's ok, because it seems pretty clear that 
you actually care about finding answers (or at least compromises) rather 
than just lobbying for your pet preferences.

In the IETF, that kind of participation is a breath of fresh air.

d/

-- 

  Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Tue, 20 Dec 2005 22:00:49 -0800

>>technical objectives and the group clearly documents the reasons for
I don't really see much difference between the two sentences.  In one
case, the bar is "necessary for the success of the specifications" while
in the other case it's "required to meet the group's technical
objectives" (and hopefully the group's technical objectives are for the
success of the specifications).  In one case, non-backwards-compatible
changes are not encouraged, while in the other, every reasonable attempt
is made to keep things compatible.

It's a significant precedent that IETF charters have included language
of this sort when there has been a deployed base at the time the WG is
chartered.  But can someone explain what's different in this wording
that warrants departing from the version on which there seems to be
rough consensus?

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 Dec 2005 08:16:51 +0000

Ted,

Ted Hardie wrote:
> implies the need to be clarify the charter in two ways.  The charter needs 
 > to reaffirm that the IETF has change control over the specifications
 > at this point, so that there is no question over who gets to decide
 > whether an incompatible change is necessary.

I think that this is motherhood and apple pie, and would have no
objection to inclusion of a reasonable statement along these lines.

But it might take a while to agree what's "reasonable" and since
Dave's right that this would be a kind of impactless change
to text that did take some time and effort already, I'd rather not
have a prolonged discussion on the topic.

Meanwhile, as a point of fact, the DKIM specification has already
changed in one on-the-wire incompatible way (canonicalisation), as
a result of a bug. I also expect another wrt. hashing since sha-1
is probably not the right thing to use anymore. So, there is an
existence proof that the current set of authors are willing to
change the specification in response to review.

(The suggestion that all charters have some implicit boilerplate
that'd include such IETF change control phrasing does sound like
a reasonable thing to discuss sometime.)

> The charter also needs to indicate that the working group will 
 > consider the relationship of this work to other, existing IETF
 > technologies.  That does not imply that it needs to adopt them,
 > but explaining why it chose to use, for example, this signature
 > mechanism rather than one of the existing ones would help the
 > IETF understand whether this mechanism is a better point
 > solution, implies a problem with the existing mechanisms which
 > should be fixed in the existing solutions, or should be considered
 > as the basis of a more wholesale replacement.

Just checking. You're referring to the "why not s/mime" question
here, right? I think answering that question is reasonable (and
has a good answer). The putative DKIM WG is not however the
place to expect an answer to "why don't we all use s/mime" as
I'm sure you agree. Its quite possible that answer to the
first question might help answering the second one, but I
wouldn't want to raise too many expectations.

(BTW I fully agree with what Barry said on this too.)

> Doing so in its first milestone document seems like a reasonable 
 > way to accomplish this, but doing so in the standards-track
 > specifications also seems reasonable.

Well, we included an overview deliverable which is intended to
capture all that kind of stuff. Its the last deliverable but
of course that doesn't mean that that particular piece of
text won't exist earlier. If you're thinking that the IESG might
want to see/discuss the "why not s/mime" answer during IETF
last call on the protocol spec, I guess that's reasonable.
Requiring that that answer be part of the last-call document
or the threats document doesn't seem like the best way to
handle this though.

Stephen.

---

From: John C Klensin <[email-masked]>
Date: Wed, 21 Dec 2005 06:23:26 -0500

--On Tuesday, 20 December, 2005 18:50 -0800 Dave Crocker
<[email-masked]> wrote:

>>> Having this point in this charter mostly serves as a
>>> statement of  mistrust, rather than providing any useful
>>> education or constraint.
>> 
>>...
> 1. You said you disagreed, but then provided an argument for
> not trusting participants ("people who do not understand the
> IETF rules".)
>...

Dave,

As I am sure you will recall, I've been very concerned since you
first proposed this about the notion of a WG that starts on the
assumption that almost all of the work is done and proven in the
field and that the IETF's role is limited to fine-tuning that
really does not change anything... unless the feature to be
changed is definitively proven to "not work".   I believe that,
in situations that are superficially similar, my colleague Dave
Crocker has argued that the IETF should not take on the work at
all because there is no value added other than endorsement.  But
perhaps my memory is bad or this situation is subtly different.

It seems to me that you and your colleagues have asked for a
charter constraint that asserts wide deployment and, on that
basis, appears to constrain the choices and changes the IETF can
make.  I am sympathetic to the desire for that constraint but I
think we all need to accept that it is an unusual request.
Because it is unusual, it also seems to me that

	 (i) you are obligated to demonstrate that sufficient
	production-level deployment actually exists to justify
	such a request and that it has been successful in
	solving whatever problem the proposed work is intended
	to solve.  Normally, that would be a ridiculously
	onerous requirement to place on a charter proposal for a
	WG.  But, because this effort has requested --and
	written into the draft charter-- some unusual
	restrictions on the IETF on the basis of the deployment
	level, the situation, IMO, changes: if you want or need
	the restrictions, then you should be willing to accept
	the added scrutiny and text.   While I am convinced that
	a great deal of effort, collaboration, and compromise
	have gone into the current proposals, I have yet to see
	evidence of significant and successful deployment.
	
	(ii) this WG proposal and several of your recent
	comments request that IETF give up most design control
	--including the ability to determine whether the need
	for a change is significant enough to be considered --
	before (from an IETF process standpoint) the effort has
	started.  I completely agree with you about the
	difference between "broken" and "maybe could be made
	better" and the importance of understanding where to
	draw the line.  But the intent of this charter appears
	to be to vest the decision about what changes are
	appropriate (or not) entirely in the self-designated
	leadership of the WG, placing constraints on the usual
	processes of review and interactions.   It is
	reasonable, IMO, for the IETF to respond by including in
	the charter things that would be obvious were the WG
	more normal and conventional, and even to impose some
	extra conditions that would be unusual for a more
	conventional WG setup, simply to stress that those
	elements of WG operation and review had not changed.
	
	(iii) you are obligated to be quite explicit about the
	value added by IETF involvement given those constraints,
	much more explicit that would be expected of a normal WG
	that had not requested the constraints.

There is certainly a case to be made that the push-back you are
getting would be unreasonable were this a conventional WG
charter proposal.  But, because of the request for constraints
on permitted changes, it is not a conventional WG charter
proposal and suggestions about additional review, additional
constraints, and specific additional language all seem to me to
be appropriate as a result.  

> 2. You cannot seriously think that adding the language Ted
> suggests -- [...] -- will make any difference to the working
> group process.

Viewed in the light of the above, some language along the lines
I think Ted and others have suggest might actually be quite
valuable in delineating how far the WG (or its leadership) is
expected or permitted to go in application of the requested
"restricted changes" principle.  Such language could be useful
in documenting an agreement, setting expectations, and
preventing future misunderstandings.   Should it be the
community's expectation that having such agreements, and having
them documented, would not "make any difference to the working
group process", then the WG should not be chartered... but I'm
sure you did not intend your comment to be read that way.

> 3. Adding such language is not a remedy for bad working group
> management or participation, yet that is exactly what Ted and
> you seem to be targeting.  Since it does not target technical
> details of the work to be specified -- remember you said
> "education" -- that means that we now need to make charters
> bullet-proofed against an essentially infinite range of
> misunderstandings, as well as presuming that participants are
> not to be held responsible for reading basic IETF materials.
>...

While YMMD, I see a level of hyperbole in the above paragraph
that I don't consider appropriate or efficient if the goal is
making progress on finding a set of charter provisions that are
acceptable to both the proponents and the broader community.

>... 
>> The same reasoning above applies here. Having people whose
>> sole  involvement with the IETF is one new WG know that there
>> is an 
> 
> You are attempting to impose a new requirement for a charter,
> namely that it be bullet-proofed against ignorant participants.

Perhaps that was Paul's intent, but I didn't read his comment
that way.  For me, the key unusual property of this WG proposal
is the claim  and request that the IETF constrain itself, a
priori, about the questions that can be asked and the changes
that can be made.  Without trying to guess at what consensus
will emerge from the community about whether that request is
reasonable, it seems to me that requests for additional language
to delimit, explain, and emphasize its boundaries are entirely
in order.  If you find such requests unreasonable because they
explain or reiterate the obvious  or impose new requirements,
then an appropriate remedy would be to remove the (suggested)
constraint that makes the effort unusual.

> That sounds like an interesting item to pursue in the IETF
> process enhancement discussions, because the expectation of
> such content in a charter is not specified in any current IETF
> process documents.

Nor does any current IETF process document anticipate a charter
that constrains the IETF's ability to make changes to a
preexisting specification or that intends to pre-judge the
changes that can be made.  If one were trying to kill the DKIM
effort procedurally, one would say "a WG with these formal
constraints on IETF-introduced changes is not covered in any
current process documents, so a charter should not be approved
until the norms for a group requesting such constraints are
established through the process enhancement discussions".   No
one appears to have said that, which I consider an Extremely
Good Thing.  However, to the extent to which a WG is proposed
with unusual constraints on the community, it seems to me that
community discussion of corresponding additional constraints,
requirements, or explanatory language is entirely in order.

>...
> 2. You are presuming that it is reasonable for someone to come
> in at the end of a working group and require a defense of the
> initial position of the work.  Since such a question belongs
> at the beginning of the process -- assuming that anyone has
> noticed that this work continues existing work rather than
> creates new work -- it is not productive to have such basic
> challenges lodged at the end of the process.

Hmm.  This clearly is not the "end of a WG", a situation to
which I would join you in objecting.  But I trust you will agree
that there needs to be some appropriate time for the community
to raise these issues, expect a response, and be able to
evaluate that response.  Usually, the optimal time is when a
charter is proposed and under review, but that is exactly what
is being done here, so I don't see the objection... unless you
believe that the "basic challenge" should have been imposed at
"the beginning" where that is defined at the initiation of a
design team process that was conducted out of sight of the IETF
process and not subject to IETF rules about openness and
participation.  At least as important, as you pointed out...

> 1. The question has been discussed and explained at length on
> the mailing list, the two BOFs, and elsewhere, for the last
> year.

My impression has been that a significant fraction of the
community did not find the discussion and explanation
satisfactory and/or persuasive.  Now, when there is a request to
approve a charter, is precisely the one at which there needs to
be community rough consensus as to whether the question and its
answer were well-formed, appropriate, and convincing.  It seems
to me that trying to suppress the question on the basis that
explanations have been given before --explanations that some
have found unconvincing-- can be taken only as resistance to
community input.  I'm sure you didn't intend that reading.

>... 

>>>  > Since experimentation resulted in significant Internet
>>>  > deployment of these specifications, the DKIM working
>>>>  group will make every reasonable attempt to keep changes
>>>>  compatible with what is deployed, making incompatible
>>>>  changes only when they are necessary for the success of
>>>>  the specifications.
>>> 
>>> As I argued on the DKIM working group list, I think this
>>> text is a bad idea. Part of IETF having change control of a
>>> specification is having the ability to make changes, and the
>>> bar of "necessary to the success of
> 
> And Eric seem to keep ignoring, the question of how much
> change to target, when taking in existing technology, is an
> established point that has been experienced a number of times
> already.  Different choices have been made.  Those seeking to
> field DKIM have reached a consensus on charter language that
> reflect their choice for this case.  (In other words, Eric,
> rough consensus has been established on this issue.)

As you have already deduced from the above (and from our
correspondence of several months ago) I share Eric's basic
concern.   I won't reiterate those discussions and I think the
discussion above summarizes my view that, if the group is going
to ask for this type of constraint, it is reasonable that the
community delimit the constraint and related behavioral
possibilities to the degree it believes appropriate.  But I do
not accept the assertion that "rough consensus has been
established".   I am certainly prepared to believe that
consensus --rough or better-- has been established among the
proposers.  But the question here, as I see it, is whether there
is community consensus for accepting a charter that contains a
provision that is very unusual in our history rather than
letting the WG and IETF community sort out, as the work
progresses, which changes are appropriate and which ones are not.
 
> The impression, at this point, is that those seeking to remove
> all limits on the technical changes in fact have no interest
> in protecting the existing work.

See comment about hyperbole above.
 
> In that light, the folks who developed DKIM would be quite
> seriously crazy to hand it over to the IETF.

One of the things I'm having trouble understanding is why you
want both a strong constraint on changes and a WG.  If the
experimental work has resulted in wide deployment, and that
deployment has been successful to the extent that the WG should
be limited to making only those changes that are either trivial
tuning or demonstrably needed on the basis of a clear "doesn't
work" situation, it would seem more appropriate to simply submit
the documents for standardization along the individual
submission path, saving the WG resources that we both keep
pointing out are limited.  That path would, of course, raise the
question of whether the IETF was adding value, but that question
follows from the "limited changes" constraint anyway and the
value requirement and threshold would presumably be lower for
something that could be expected to consume fewer resources.  

>...
>> It is fortunate that the Atompub WG didn't have language like
>> this in  our charter, because we made many improvements from
>> the widely-deployed,  pre-IETF Atom 0.3 spec.
> 
> And presumably that was the choice of those forming the
> working group, doing the work, and/or planning to deploy the
> result.  In the case of DKIM, the decision came down in a
> different place.

I don't think you can make that assertion at this stage, and
maybe that is the essence of our disagreement.   My
understanding of what happened with Atompub is that the WG, in
the process of doing the work and considering deployment,
interoperability, and so on, made those decisions.   That is
perfectly reasonable; it would have been equally reasonable had
they made the opposite choice.  But, with DKIM, you are trying
to preempt that decision-making process in the WG by setting the
decision into the charter.  I can't speak for Eric, but I'm
finding that early-decision process -- based on a conclusion
reached by what, from an IETF process standpoint, is the
membership of a self-selected design team-- somewhat troubling.

      john

---

From: Barry Leiba <[email-masked]>
Date: Tue, 20 Dec 2005 21:04:58 -0500

> the IETF has done work on message signing before,

I believe the discussion Ted suggests IS in scope for the working group we're
proposing to charter, and I don't believe that the charter text in question
affects that.  It will be up to the WG chairs to judge rough consensus on the
discussion, or to decide, should it happen, when the discussion has become
fruitless and wasteful of the WG's time, especially considering the short
schedule that's proposed.  If Russ should choose me as a co-chair of the DKIM
WG, be assured that we WILL have this discussion.  Be also assured that I
won't let it turn into a rathole and impede progress.

I believe that is the balance that has to exist in any WG, and that the ADs
place a good deal of trust in the WG chairs to both allow discussions that
ought to happen, and control discussions so they stay within the scope of the
WG and do not get out of hand.

I don't think that anything we say in the charter changes this; it is meant
to provide a guide for resolving the ratholes and distractions.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 21 Dec 2005 05:36:08 -0800 (PST)

> 	such a request and that it has been successful in

There is no wide deployment of DKIM. What is there are several test
machines on the order of couple dozen. There is larger deployment of
DK on the order of several hundred active mail servers doing signing
(including some large ones like outgoing webmail servers @yahoo &
google; DKIM is different and they all have to change anyway), but it 
does not even closely comes to something that can be said to be wide 
deployment or existing protocol.

What is there however is a lot of hype and marketing created by Yahoo
and associated organizations about DK & DKIM being a solution to SPAM
(which as we know is not really true). I do not think it's that good
when marketing is being used to justify going against IETF normal 
procedures and instead of working out system on public MASS WG as 
originally planned, to go around IETF and create proposal in private
and then present to IETF for a stamp of approval.

I also think that if allowed to be presented alternatives to putting 
public keys in DNS, those would technically be found superior and less 
damaging to internet. Other aspects of proposal also had alternatives
that are superior, but by bypassing MASS and presenting DKIM in current
form with constraints on discussion, all that "mess" is avoided. No
matter if we end up with good system or not, I believe in the end IETF
and internet in general lost on how it all happened because IETF showed
that it can be fairly easily manipulated and for Internet there is no
guarantee that what comes out as standard is technically best approach
to solve the problem and that such approach is really vendor-neutral in 
how it was conceived.

But perhaps that marketing wins over technically best is how it really
works in the real life of corporate business (i.e. think about why
Microsoft products are used) and that is not as bad as I think that
IETF is being put inline with such vendor-dominated business world.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Wed, 21 Dec 2005 08:28:44 -0800

John,

> really does not change anything... 

1.  "fine-tuning that really does not change anything" is a
mis-representation of what I have described.

2.  I did not "propose" anything.  I noted that the transfer of existing
technology into the IETF has an inherent issue with deciding whether to
protect existing work and how much to protect it, and I noted that this
is a long way from the first time the IETF has chosen to protect quite a
bit.

3.  What work do you want to have done by the working group that is
prohibited by the the charter language in question?

>     I believe that,

or perhaps not so subtly.

Does "superficially similar" mean "not really similar"?

In any event, I'm sure you can substantiate your claim, here. It would
be a shame for such an assertion not to be amenable to deeper evaluation.

> charter constraint that asserts wide deployment and, on that

I believe the language that has been used does not match the language
you are using.

> 	production-level deployment actually exists to justify

John, if you do not care about 2 years of prior technical, development 
and deployment prior work, then please simply say so.

If you do not care about 5 months of open-participation discussion and
revision to the charter that reached rough consensus on the draft
charter text *twice*, then please simply say so.

Welcome to the modern IETF.

Infinite time to raise abstract principles, absent any specific
technical concerns.

No time to focus on concrete work.

An excellent productivity disincentive for the community.

d/

-- 

  Dave Crocker

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 21 Dec 2005 18:01:12 +0100

--On onsdag, desember 21, 2005 05:36:08 -0800 "william(at)elan.net" 
<[email-masked]> wrote:

> form with constraints on discussion, all that "mess" is avoided.

My usual immediate response to anything that contains the phrase "allowed 
to be presented" is "where's the draft".

MASS had its BOF and its mailing list, so I'm assuming that whoever 
participated in that discussion discovered the fact that they could publish 
an internet-draft for ANYTHING without prior approval, as long as it was 
done in their own name and not in the IETF's.
So in this case, the drafts might actually be out there.

If so - what's the draft names?

                        Harald

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 21 Dec 2005 09:23:15 -0800 (PST)

On Wed, 21 Dec 2005, Harald Tveit Alvestrand wrote:

> My usual immediate response to anything that contains the phrase "allowed to 
> be presented" is "where's the draft".

Yes, the drafts and proposals were published as part of MASS.
I have links to most of that at:
  http://www.elan.net/~william/emailsecurity/emailsignatures-comparisonmatrix.htm

Yes, the DKIM group clearly purposely bypassed discussions as part of
MASS (i.e. ietf open forum) in order to do it in private and leave only 
one authorization method (i.e. public keys in dns; it so happens that
public keys in dns is also core of the Yahoo's patent and other 
authorization method do not have such IPR constraints).

And yes in case you don't know BoF chairs and AD did deny request to
present alternatives to DKIM when it was still called MASS BoF.

---

From: Keith Moore <[email-masked]>
Date: Wed, 21 Dec 2005 16:16:21 -0500

> changes to deployed code. 

I think that's an overgeneralization.   There's neither a wide enough
deployment of DKIM, nor sufficient evidence of DKIM's suitability for
the diverse user community, for the current DKIM specification to
dictate the standard protocol.

---

From: Keith Moore <[email-masked]>
Date: Wed, 21 Dec 2005 16:10:07 -0500

> > implies the need to be clarify the charter in two ways. 
> 
>  The charter needs to reaffirm that the IETF has change control over
> the specifications at this point, so that there is no question over who
> gets to decide whether an incompatible change is necessary.  The
> charter also needs to indicate that the working group will consider the
> relationship of this work to other, existing IETF technologies. 

I'll go further than that.  The text you quoted from the proposed
charter is inappropriate, and needs to be removed entirely.

DKIM as currently envisioned has serious flaws that not only limit its
flexibility but which will do harm to domains that do not fit its
Procrustean model for policy advertisement.  The flaws are fixable, and
with the fixes DKIM could be quite useful for discouraging forgeries.
But the flaws aren't fixable without making incompatible changes. 

The "only when necessary for success" clause raises the bar for changes
too high.  At best it is confusing because different people define
"success" in different ways.   There are unfortunately some DKIM
proponents who want IETF to rubber stamp this protocol, despite its
widely acknowledged flaws.   If this clause is allowed to stand they
will try to use it as a stick to prevent changes that would make DKIM
much more widely applicable.

The DKIM working group should have complete latitude to change any
feature of the current DKIM protocol.  The DKIM protocol is neither
widely deployed enough nor useful enough in its current form to dictate
features of an IETF standard protocol.

---

From: Keith Moore <[email-masked]>
Date: Wed, 21 Dec 2005 16:21:27 -0500

> choices. 

That is almost never an appropriate goal for an IETF working group
creating a standard.  The goal of a standard-setting working group is
to understand and describe what will work well for the Internet as a
whole and to vett that design via wide review, not to rubber-stamp what
has been designed by a small group of people and deployed under
relatively limited circumstances.

> Earth to Ted:  THAT'S NOT THE JOB OF THIS WORKING GROUP.

Dave, you are not the one who decides what this working group does.
that's IESG's job.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 21 Dec 2005 16:30:41 -0500

Dave,

You keep making statements like that without a shred of support for
your position. You seem to think that you alone dictate the conditions
under which a working group should be chartered. You are mistaken,
and IMHO your efforts are hindering progress of the the DKIM effort.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 21 Dec 2005 16:34:26 -0500

> that warrants departing from the version on which there seems to be

there isn't a DKIM WG yet, so "rough consensus" of the mailing list is irrelevant.

---

From: Nathaniel Borenstein <[email-masked]>
Date: Fri, 23 Dec 2005 17:27:49 -0500

I generally try to stay out of discussions when everything has already 
been said a thousand times, but this one is too important to ignore, 
and I fear that people are arguing over red herrings rather than 
speaking plainly about the underlying issue.  So in what follows I will 
try to give a reasonably simple explanation of why a bunch of long-term 
IETF guys decided to form a private group to develop DKIM:

On Dec 21, 2005, at 12:23 PM, william(at)elan.net wrote:

> MASS (i.e. ietf open forum) in order to do it in private and leave 
> only one authorization method

This is completely backwards, the precise opposite of why a few of us 
decided to start a closed, private group to define what became DKIM.   
Far from trying to "leave only one authorization method," the DKIM 
effort is an attempt to show, by example, how an arbitrary number of 
such methods might eventually be elaborated and standardized.  It is an 
attempt to define one method first, as a step towards defining as many 
of them as possible/necessary rather than arguing endlessly over which 
is best.  For most of us, support for DKIM does NOT imply opposition to 
any other proposals related to controlling spam and related ills.  A 
lot of us who have worked on DKIM were previously active in trying to 
bridge the gap between SPF and Sender-ID, and despite the 
disappointments we'd still like to see that effort succeed, as well as 
quite a few other anti-malware ideas and technologies.

To explain our reasoning, I must first posit a "reasonableness rule" 
for spam/malware control (and, in what follows, I will use the term 
"spam" broadly to include phishing, spim, viruses, and other 
communication malware):

> There are no silver bullets to "solve" spam, and our best hope is to 
> standardize and implement as many of the technically-feasible proposed 
> anti-spam mechanisms as possible, maximizing their ability to 
> cooperate while minimizing any technical and political barriers 
> between them.

Most folks who have taken a long, serious look at these problems seem 
to agree with the substance of the above paragraph.  The only people I 
know of who disagree are the ones who believe they have a handle on 
"the" solution.  Those people tend, by definition, to be disruptive in 
discussions about any solution other than the one they advocate.  The 
decision to "go private" to develop what we now call DKIM was made, 
quite consciously, to keep those people (and too large a crowd) *out* 
of the early stages of the detailed design.

I, for one, don't take lightly the notion of shutting anyone out of any 
part of the standards process.  But the history of IETF spam-related 
efforts has so far been one of total, absolute, abject failure, and it 
is worth trying to understand why.  I believe that the problem is first 
of all one of simple numbers:  Any discussion of spam control attracts 
so many interested parties as to swamp the normal IETF processes.  
Worse still, however, the spam topic also attracts (IMHO) more than the 
usual percentage of fringe voices.  (Please note that by fringe voices, 
I mean people whose technical insight might have outpaced their ability 
to forge consensus.  Fringe voices can be right or wrong, sane or 
crazy, just not currently in the mainstream.)

Anyway, presuming the above "reasonableness rule,"  what we need is for 
advocates of each "family" of spam control approaches to generate 
detailed, consensus-oriented specs about a standardized way to 
implement one particular approach to spam control., and to be maximally 
compatible with the other methods.  Unfortunately, this is such a 
reasonable and boring idea that when one presents it to any 
large-enough antispam forum, most people quickly agree, but the rest go 
on fighting about which approach is best.  Such arguments seem to be 
much more exciting, for many, than the very hard work of trying to make 
"all of the above" work.

Frankly, watching this happen multiple times has made many of us wonder 
if the IETF could ever rouse itself to a serious attack on spam and 
related problems.  We started the DKIM design process in private, to 
test the only promising idea I'm aware of:  beginning in a forum that 
is closed, but full of widely respected open standards veterans, to 
produce a highly-polished first draft of a proposed standard for ONE of 
the many spam control mechanisms being advocated in the wider, less 
focused forums.  The goal, from day one, was not to close *anyone* out 
of the process, but to nurture a protected, focused environment in 
which to more fully elaborate a single, specific technical proposal 
before subjecting it to the wild open winds of the IETF.  (To push the 
metaphor further: the IETF climate for spam discussions has become 
harsh enough to require nurturing seedlings in a greenhouse until 
they're hardy enough to survive.)

Although I know that the arguments about the charter are being made in 
good faith, after working on this for two years it's hard not to see 
them as a great big red herring.   I can't help but think that the real 
argument isn't about the degree to which we want to favor compatibility 
with the existing spec.  Whatever the charter says, I promise you that 
if someone comes up with a better way to do domain-level email signing, 
it will get a fair hearing.  The real issue is whether we'll permit the 
reopening of the larger "which anti-malware technique is best" 
questions that are guaranteed to torpedo the effort.  More 
fundamentally, the question is whether or not the IETF will EVER be 
able to facilitate progress on multiple independent fronts in the 
battle against spam, phishing, and the like, or whether we simply 
prefer to argue about which technique is the best.  Frankly, we chose 
domain-level authentication as our first project because it looked like 
one of the *least* controversial targets.  (I won't even dare say in 
public, at this point, what I think the next projects should be.)  If 
we can't create a WG that is acknowledged, by charter, to focus on this 
one very specific *type* of malware control technology, I personally 
will be about ready to give up on the IETF for any problem this hard.  
(I have so far been a strong advocate for doing this work in the IETF.)

On the other hand, if all the people who think that DKIM advocates are 
barking up the wrong tree would simply start their OWN (public or 
private) design groups, to flesh out and standardize their own 
approaches, we'd all be a lot better off, and most of us would support 
most of those efforts.  I personally think we need at least two dozen 
new standards for email malware control, of which DKIM might, if we're 
lucky, prove to be the very first.  (What we should *really* be 
discussing is setting up a new IETF "Malware Area" to house these 
efforts, which sit uneasily in the Procrustean beds of the Security or 
Applications areas.)

Let's be honest:  We're not really arguing about the degree to which 
the WG is biased towards the specifics of the DKIM draft, but rather 
whether or not it is "biased towards" (I would rather say focused on) 
this one fundamental approach to the exclusion of all others.  The real 
issue is whether or not the WG will permit the reintroduction of 
discussions about whether the whole domain-based approach is the 
"right" way to go for spam control.  The fact is, it's not.   There is 
no right way, no silver bullet.  If there's another approach that you 
favor, let's flesh it out as well, eventually in its own WG.  But we 
won't get anywhere useful by consigning DKIM to death by a thousand 
bureaucratic cuts.

Domain-level email signatures are a pretty good idea, one of many that, 
taken all together, just *might* help us preserve the utility of email 
and other open electronic communications.  The purpose of the new WG 
should be to produce the best possible domain-level email signature 
standard, using DKIM as a concrete but reasonably flexible starting 
point.  Nobody is going to argue against considering really meaningful 
improvements to DKIM, even if they introduce incompatibilities, but 
neither will anyone benefit from reopening the question of whether 
domain-level email signatures are worth doing at all.  We need to 
charter a WG to produce as good a version of this one idea as possible, 
and move on to the next idea.  If we can do that, and can then repeat 
the process another twenty or so times, we *may* begin to see some real 
progress on spam, phishing, and the like.  Isn't that going to be hard 
enough without this kind of squabbling over each little step?  -- 
Nathaniel

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 23 Dec 2005 18:18:26 -0800

Nathaniel Borenstein <[email-masked]> wrote:
> this one fundamental approach to the exclusion of all others.

Well, that may not be what you're arguing about, but it's certainly
what I'm arguing about, at least at the present moment.

The language under debate doesn't impact the question you raise one way
or the other. The first paragraph of the charter quite clearly states
that the WG will be working on domain-level signatures. So, the language
under debate is purely about ruling out incompatible changes that still
fall along these same general lines.

> Domain-level email signatures are a pretty good idea, one of many
> that, taken all together, just *might* help us preserve the utility of
> email and other open electronic communications.  The purpose of the
> new WG should be to produce the best possible domain-level email
> signature standard, using DKIM as a concrete but reasonably flexible
> starting point.  Nobody is going to argue against considering really
> meaningful improvements to DKIM, even if they introduce
> incompatibilities, 

Then why the push to have charter language designed to do exactly
that? 

-Ekr

---

From: Douglas Otis <[email-masked]>
Date: Sun, 25 Dec 2005 00:09:23 +0300

On Fri, 2005-12-23 at 17:27 -0500, Nathaniel Borenstein wrote:
> such methods might eventually be elaborated and standardized.

There is danger viewing any abuse control mechanism as representing a
"authorization" scheme.  The control method should strive to identify
the source of abuse, and not just whether the message has been
authorized.  The DKIM signature provides a fairly strong indication of
the message source, with a normal potential for abusive replay as with
any cryptographic method.

> It is an attempt to define one method first, as a step towards
> defining as many of them as possible/necessary rather than arguing
> endlessly over which is best.  For most of us, support for DKIM does
> NOT imply opposition to any other proposals related to controlling
> spam and related ills.  A lot of us who have worked on DKIM were
> previously active in trying to bridge the gap between SPF and Sender-
> ID, and despite the disappointments we'd still like to see that effort
> succeed, as well as quite a few other anti-malware ideas and
> technologies.

Those who envision SPF or Sender-ID as a means to control spam, clearly
have not considered the inherent weakness in an "authorization" scheme.
Bad actors are adept at adopting any such authorization.  Reputation
remains the only solution able to abate the bulk of abuse.  When
reputation is applied against an "authorization" as an identifier,
innocent email-address domain owners will be seriously harmed.  Abusers
will find acceptance methods for an authorization scheme.

To abate abuse, name-based identifiers are needed to overcome growing
exploits. Reliance upon "authorization" as an abatement control must be
avoided as inherently unfair.  The DKIM signature can identify the email
source, and when considered independent of any email-address, can
establish non-disruptive reputation based abatement controls.  A
verified EHLO can also serve the same purpose.  There are drafts and MTA
extensions available today to offer this similar low cost solution.

If the desire were really to abate abuse, there is no mystery what can
help.  CSV, BATV, and the base DKIM would be examples of schemes that
can identify email sources.  Name-based schemes can significantly reduce
the amount of spam when coupled with fair reputation assessments.

Authorization is clearly not an abatement solution.  Authorization
should be seen as a method to shift the burden onto the email-address
domain owner.  The outcome of an authorization strategy in today's
shared environments would likely damage the reputation of most email-
address domains.  The exception may be for the mega-domains less
sensitive to reputation assessments simply due to their size.

DKIM should be devised to exist without requiring an authorization
scheme to handle message replay or unsigned messages.  When MTAs and
MUAs are designed to recognize the source of email using DKIM
signatures, reliance upon authorization (or reputation) for spoofing
protection would be unnecessary.  Reliance upon visual examination that
often involves acquiring every look-alike domain may also become
unnecessary.  Recognition ability could be rapidly included in the MTA
to offer immediate protections for commonly spoofed domains, while
avoiding the disruption an "authorization" scheme is sure to cause
current email practices.

-Doug

---

From: Nathaniel Borenstein <[email-masked]>
Date: Sat, 24 Dec 2005 22:36:12 -0500

On Dec 23, 2005, at 9:18 PM, Eric Rescorla wrote:

>> Nobody is going to argue against considering really

My opinion?  Because nobody is really confident they know what other 
people would consider "really meaningful improvements" and are thus 
trying to "set the bar" at a level that makes them comfortable.  (And 
to be fair, I don't read  anything in the text as saying that we'll 
ignore really meaningful improvements if they're incompatible.  I 
suppose one could imagine a "really meaningful improvement" that isn't 
"necessary for the success of the spec" but I think I would have to try 
pretty hard to come up with a tangible example where A) this would 
matter, and B) the text of the charter would cause the WG to do the 
wrong thing.)

Whatever the charter ends up saying, one can imagine that the WG would 
be completely fair and open to improvements, or that it would ignore 
them all and attempt to steamroll a rubberstamping (a very smelly mixed 
metaphor).  The words in the charter aren't really going to make a 
nickel's worth of difference either way.  The power of a WG chair to 
act independently of the words of a WG charter is even greater than the 
power of a politician to act independently of the laws, and that's 
saying a lot.  People are arguing about wording that is remarkably 
unimportant, in my mind.  -- Nathaniel

---

From: Nathaniel Borenstein <[email-masked]>
Date: Tue, 27 Dec 2005 10:33:07 -0500

> any cryptographic method.

I'm sorry, the "authorization method" was an echo of the term used in 
the mail I was replying to (which is why it was in quotes).  I was 
really trying to generalize to a whole range of technologies without 
making my wording too awkward.  Perhaps I should have replaced "such 
methods" with "antimalware technologies" or "abuse control mechanisms." 
  In any event, I fully agree that the term authorization, in this 
context, is both A) insufficiently generalized, and B) troublesome  on 
countless philosophical grounds.

> Reputation remains the only solution able to abate the bulk of abuse.

The word "only" makes me cringe a bit in any discussion like this (a 
global fascist state, for example, is another possible solution), but I 
think most of us pretty much agree about the critical role of 
reputation.  I see the cycle as going like this:  We need at least one 
standardized, moderately-useful system for weakly authenticating the 
sources of messages.  Once we have that, we have the minimal data that 
a reputation system will require to be able to start doing something at 
least mildly useful.  Once we have *that*, we will have (in our 
reputation systems) a built in "market" for additional systems for 
(perhaps less weakly) authenticating the desirability (not necessarily 
solely due to the source) of incoming messages.  To some extent, 
there's a chicken-and-egg problem with authentication and reputation 
technologies.  My hope for DKIM is that it will give us one good enough 
egg to produce a chicken, which can then (in much the manner that Cain 
and Abel found their wives, I guess) facilitate a whole new generation 
of authentication technology eggs.

> When

Yes, every one of these schemes will be flawed.  That is why we need to 
understand A) the role of "weak authentication" (weeding out some but 
not all of the bad guys at any point in time, and using multiple 
sources of information to judge the desirability of a message) and B) 
the need for a continually evolving set of (ever-stronger, we hope) 
mechanisms for proving that a message is desirable to the recipient.  
Some of those mechanisms will also involve (ever-stronger, we hope) 
sender authentication, but others could eventually involve technologies 
as unrelated to authentication as anonymous payment.  -- Nathaniel

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 27 Dec 2005 07:46:48 -0800 (PST)

On Fri, 23 Dec 2005, Nathaniel Borenstein wrote:

> I generally try to stay out of discussions when everything has already been 
> said a thousand times, but this one is too important to ignore, and I fear 
> that people are arguing over red herrings rather than speaking plainly about 
> the underlying issue. So in what follows I will try to give a reasonably 
> simple explanation of why a bunch of long-term IETF guys decided to form a 
> private group to develop DKIM:

I think simple explanation is the one you can fit in one sentence, this
wasn't it...

>> one authorization method
> decided to start a closed, private group to define what became DKIM.   Far 
> from trying to "leave only one authorization method," the DKIM effort is an 
> attempt to show, by example, how an arbitrary number of such methods might 
> eventually be elaborated and standardized.  It is an attempt to define one 
> method first, as a step towards defining as many of them as 
> possible/necessary rather than arguing endlessly over which is best.  For 
> most of us, support for DKIM does NOT imply opposition to any other 
> proposals related to controlling spam and related ills.  A lot of us who 
> have worked on DKIM were previously active in trying to bridge the gap 
> between SPF and Sender-ID, and despite the disappointments we'd still like 
> to see that effort succeed, as well as quite a few other anti-malware ideas 
> and technologies.

Talk about "red herring". I specifically meant authorization method
used with email automated (mailserver-added) signatures and you change
the subject be different kinds of email "authorization" systems. I'm
in fact all for different types of systems and supported wider view
of the problem and use of multiple tools (if they don't interfere
with each other), but not standardization of closed designs.

So what is true is that I did not get it wrong. MASS originally was 
discussing several authorization methods: public keys in DNS, 
fingerprints in DNS (and in special HTTP fingerprint server),
X509 certificates located on HTTP server and X509 certificate servers.

In DKIM however there is left only public key in dns (and talking about
other methods would be excluded by means of the working group charter)
and I do not believe this issue was ever properly decided on and my
argument is that there should be more authorization methods being
available (in initial release, otherwise they'd never really get deployed)
because public keys retrieval from domain root is too limiting and can 
not for example fit all scenarios well; plus I think this "chosen" method 
is in fact the worst one [based on possible impact to infrastructure]
of those available (although it does have large vendor supporting it
and only it as usual...)

For reference as to how it all occurred you might want to go back one
year and glance at
  http://web.archive.org/web/20050204075618/mipassoc.org/mass/crocker-features-iim-dkeys-09dc.htm
and that might make you wonder what is ESTG (care to guess about what
this acronym stands for...) which has its own meetings and mail list -
  http://mipassoc.org/mailman/listinfo/estg-general
it was mentioned on ietf too:
  http://www1.ietf.org/mail-archive/web/ietf/current/msg39474.html
BTW - even more interesting message was recently leaked out of it:
  http://www.mhonarc.org/archive/html/ietf-dkim/2005-12/msg00115.html

I'm against doing standardization in limited (and especially private
and closed) forums and to me this is what it looks like MASS turned
out to be (and I really don't care if this had few "long-term IETF"
folks involved or not). When some SPF folks wanted to do their own 
standardization group I had some strong comments on their effort too.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Tue, 27 Dec 2005 10:31:42 -0800

On Dec 27, 2005, at 7:33 AM, Nathaniel Borenstein wrote:
>
> I'm sorry, the "authorization method" was an echo of the term used  
> in the mail I was replying to (which is why it was in quotes).  I  
> was really trying to generalize to a whole range of technologies  
> without making my wording too awkward.  Perhaps I should have  
> replaced "such methods" with "antimalware technologies" or "abuse  
> control mechanisms."  In any event, I fully agree that the term  
> authorization, in this context, is both A) insufficiently  
> generalized, and B) troublesome  on countless philosophical grounds.

The response was specifically against the use of "authorization."   
With respect to SPF/Sender-ID or SSP, these are indeed email-address  
"authorization" schemes.  With Sender-ID, "authorization" has been  
incorrectly described as form of "authentication", and much like  
Sender-ID, SSP appeared more by way of introduction rather than  
discussion.  All of these "authorization" schemes, especially SSP,  
will disrupt the delivery of legitimate email.  This "authorization"  
scheme also proposes untold numbers of DNS lookups for perhaps any  
number of From addresses and signatures.  The art of "open-ended  
authorizations" (burden shifting) in SSP will soon include  
"authorized" signature lists.  SSP also considers itself a "weak"  
form of "authentication" by directing complaints to email-address  
rather than the signer. : (

> The word "only" makes me cringe a bit in any discussion like this  
> (a global fascist state, for example, is another possible  
> solution), but I think most of us pretty much agree about the  
> critical role of reputation.

Some view a closed system, rather than a system open to tens of  
millions of email-address domains, as an alternative to reputation.   
Even in that austere system however, each would consider their access  
contingent upon their reputation for good behavior.  Reputation is an  
unpleasant reality where identifying those culpable for abuse _must_  
_not_ be taken lightly.

> I see the cycle as going like this:  We need at least one  
> standardized, moderately-useful system for weakly authenticating  
> the sources of messages.

I see the base DKIM draft forming a solid basis to identify email  
sources.  The ill considered SSP draft will seriously hinder the DKIM  
effort.  Serious problems are already being handled by way of burden- 
shifting, rather than considering real solutions.  The related  
expense associated with an imposition of a disruptive email-address  
authorization scheme does not justify this component's inclusion  
within the DKIM charter.  With far less overhead, spoofing attempts  
can be thwarted without email-address authorizations.  Many of the  
serious crimes depend upon embedded links rather than use of an email- 
address (which are never seen by the majority of recipients).  A  
solid basis for the source of an email-address will significantly  
enhance protective strategies.  It is a dangerously false premise  
that an authorization scheme offers protection, as any assurance in  
that regard will increase the success rate of criminal fraud.

> Once we have that, we have the minimal data that a reputation  
> system will require to be able to start doing something at least  
> mildly useful.

Please note authentication does _not_ include SSP.

> Once we have *that*, we will have (in our reputation systems) a  
> built in "market" for additional systems for (perhaps less weakly)  
> authenticating the desirability (not necessarily solely due to the  
> source) of incoming messages.  To some extent, there's a chicken- 
> and-egg problem with authentication and reputation technologies.   
> My hope for DKIM is that it will give us one good enough egg to  
> produce a chicken, which can then (in much the manner that Cain and  
> Abel found their wives, I guess) facilitate a whole new generation  

Agreed.  Do not let the ill conceived SSP derail DKIM.

>> When reputation is applied against an "authorization" as an  
>> identifier, innocent email-address domain owners will be seriously  
>> harmed.  Abusers will find acceptance methods for an authorization  
>> scheme.
>
> Yes, every one of these schemes will be flawed.  That is why we  
> need to understand A) the role of "weak authentication" (weeding  
> out some but not all of the bad guys at any point in time, and  
> using multiple sources of information to judge the desirability of  
> a message) and B) the need for a continually evolving set of (ever- 
> stronger, we hope) mechanisms for proving that a message is  
> desirable to the recipient.  Some of those mechanisms will also  
> involve (ever-stronger, we hope) sender authentication, but others  
> could eventually involve technologies as unrelated to  
> authentication as anonymous payment.

To ensure email does not self-destruct, use of reputation against  
authorizations _must_ be avoided as imposing highly unfair treatment,  
even when email practices adapt to new paradigms.  When governments  
start issuing digital postage stamps, knowing the source of the email  
message remains important.  The recognition of these sources is  
beyond visual examination that can _not_ be aided by an authorization  
scheme.  MUAs will need to assist in the recognition efforts.  DKIM  
and recognition, but not authorization!

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 28 Dec 2005 02:20:29 +0100

Douglas Otis wrote:

> The response was specifically against the use of
> "authorization."  With respect to SPF/Sender-ID or SSP,
> these are indeed email-address "authorization" schemes.

"Sender-ID" is in fact spf2.0 with two "scopes" also known
as "pra" and "mfrom".  There's no actual draft for "mfrom",
we can only guess that it's either essentially the same as
v=spf1, or it's v=spf1 minus recommended HELO checks (maybe
back to optional HELO checks as in 2004).

But for the latter to make sense we'd need another missing
draft "spf2.0/helo".  So let's asumme that "mfrom" would be
the same as v=spf1.  PRA has several technical issues, let's
forget it for the moment - until somebody manages to modify
2476bis 8.1 and 2822 3.6.6 for PRA.

For SSP we have months to discuss all technical details in
the proposed DKIM WG, I can't judge it yet.  Removing PRA
and SSP from the equation results in SPF PASS.  That can be
a PASS for the "HELO-identity", and in that case you can of
course use it (like CSV) as a base for some MTA-reputation.

Or it's a PASS for a MAIL FROM coming from one of the MTAs
"permitted" to use it.  If it's no "per-user sender policy",
built with the SPF %{l} macro (mnemonic "local part"), then
it's simply a domain based policy.

This is all very KISS, and of course you're free to use this
PASS result as it pleases you, combine it with white lists,
ignore it as irrelevant for your purposes, or extend the
white list concept to a more detailed "reputation" scheme.

There's no "burden shifting".  If you have a PASS you know
that the Return-Path is no random garbage, you can bounce or
challenge without hitting innocent bystanders.

Of course it's the problem of the domain owner to get his
SPF policy right,  Of course there's a risk of "cross-user
forgeries" if one of the permitted MTAs (or rather its MSAs)
don't implement 2476bis 6.1 or a similar solution.  I hope
that the next draft-hutzler will address this issue, as it is
it could be reduced to two statements:

1 - implement 2476bis
2 - at least MDAs should reject all garbage

Point 1 is state of the art 2476 or seven years old, point 2
is also not exactly new, relevant for a few [censored] still
believing that 2821 is the SMTP bible.  Do we really need a
separate BCP for these two points ?  2476bis is already a DS,
how dense are those folks ignoring it, and would they read
and understand a draft-hutzler BCP ?

Back to SPF PASS, I'm free to say "v=spf1 +all".  If that
backfires with whatever you do it is my problem, it's not
your problem.  A bogus SPF record is as bad as bogus MX
records, that's no "burden shifting", it's a fact of live.

It's trivial (but not cheap at about 1 US cent per minute)
to forge MAIL FROM @xyzzy coming from its permitted IPs.

But once again it's my problem if my ISP doesn't implement
2476bis 6.1 or a similar scheme.  If you get spam with a
PASS from @xyzzy hold "me" accountable for it as you see
fit.  If I'd want more security I'd know where to buy it.

And if I'm paranoid about it I could (in theory) publish
a policy with a NEUTRAL result instead of PASS for this
situation.

Over all SPF is fine, start to build something with PASS
(I'd prefer it if you stay away from C/R systems), or if
you don't like it ignore it.

So far I see no reason at all to replace SPF by one of the
other schemes, they are all less efficient, more expensive,
more restrictive, or technically flawed (pick at least two)
from _my_ POV.  I'm sure that YMMV.  I'm a KISS extremist:

821 worked, 1123 broke it, SPF fixed it, end of story.  Bye

---

From: Douglas Otis <[email-masked]>
Date: Wed, 28 Dec 2005 08:46:00 -0800

On Dec 27, 2005, at 5:20 PM, Frank Ellermann wrote:

>> With respect to SPF/Sender-ID or SSP, these are indeed email- 
>> address "authorization" schemes.
>
> There's no "burden shifting".  If you have a PASS you know that the  
> Return-Path is no random garbage, you can bounce or challenge  
> without hitting innocent bystanders.

The email-address domain owner bears the burden when email-address  
authorization is considered "weak" authentication and used to accrue  
reputation.  The burden is shifted when the email-address  
authorization does not indicate the actual sender.  In shared  
environments with millions of compromised clients, these public  
authorizations will act as invitations.  Most email-address domain  
owners will suffer harm well beyond their control, as only a few  
administer their own private servers.  Repairing exceptions only  
increases these exposures when this involves open-ended  
authorizations (by any name).

> ...
> Back to SPF PASS, I'm free to say "v=spf1 +all".  If that backfires  
> with whatever you do it is my problem, it's not your problem.  A  
> bogus SPF record is as bad as bogus MX records, that's no "burden  
> shifting", it's a fact of live.

This back-scatter problem can be resolved by implementing BATV at the  
cost of two additional wafer-thin packets.  (This would be far less  
overhead than looking up SPF records.)  Unlike the (defunct) SPF  
scheme aimed at qualifying the return-path, BATV does not wait for  
wide adoption before benefits can be derived.  The BATV signatures  
should be obfuscated upon delivery, and the same obfuscation could be  
common practice for DKIM, as described the in the options draft.  : )

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 28 Dec 2005 04:55:23 -0500

> >>
> > The 'illegal syntax' is not yet an RFC but is in
draft-ietf-netconf-ssh-05.txt
> > which says
> >    "As the previous example illustrates, a special character sequence,
> >     ]]>]]>, MUST be sent by both the client and the server after each XML
> >     document in the NETCONF exchange.  This character sequence cannot
> >     legally appear in an XML document, so it can be unambigiously used to
> >     indentify the end of the current document, allowing resynchronization
> >     of the NETCONF exchange in the event of an XML syntax or parsing
> >     error."
> > For me, that is ok; the 'illegal syntax' is part of the transport syntax not
> > part of the XML syntax and so is not illegal, if you follow me:-)
> > ...
> Why don't you use an illegal *character* instead, such as Formfeed?
> That's certainly easier to parse...
>
> Best regards, Julian

I agree, for XML, but my main concern is with UTF-8 encoded strings, where
FormFeed is a legal character, encoded as it would be in ASCII.  I was using the
'illegal syntax' to float an alternative approach, like using %xC1 - which is
illegal in
UTF-8 - to delimit a UTF-8 string, but as I say, that idea does not seem to have
caught on  within the IETF.

Tom Petch

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 28 Dec 2005 04:55:23 -0500

----- Original Message -----
From: "Douglas Otis" <[email-masked]>

> effort.

You keep saying that "every which way but loose."

The thing is, I don't agree and I know I not crazy... so. :-)

The bottom line is "for me" is NO SSP, NO DKIM. I won't bother. I won't
waste my time.    Call it want you want SSP or whatever, the process
must be consistent, and if there is NO HIGH reliable DETERMINISTIC (not
HEURISTIC) verification concept of a newly introduced entity into the
process, then its isn't worth anything.  What's the point?  We will get
swamped with YAHOO junk mail anyway and until the day YAHOO declares a
specific POLICY on how to handle its domain mail, the DKIM/DK overhead
will not be added. PERIOD.

If you wish to continue to pitch "your ideas" that's fine, but you
should really give it up already trying to convince people SSP will
crack the earth.

FWIW, NO SSP == NO DKIM.  Its worth less overhead.

That said, Have a happy new year. :-)

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

[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=subscribe>
Sender: [email-masked]
Errors-To: [email-masked]

----- Original Message -----
From: "Douglas Otis" <[email-masked]>

> effort.

You keep saying that "every which way but loose."

The thing is, I don't agree and I know I not crazy... so. :-)

The bottom line is "for me" is NO SSP, NO DKIM. I won't bother. I won't
waste my time.    Call it want you want SSP or whatever, the process
must be consistent, and if there is NO HIGH reliable DETERMINISTIC (not
HEURISTIC) verification concept of a newly introduced entity into the
process, then its isn't worth anything.  What's the point?  We will get
swamped with YAHOO junk mail anyway and until the day YAHOO declares a
specific POLICY on how to handle its domain mail, the DKIM/DK overhead
will not be added. PERIOD.

If you wish to continue to pitch "your ideas" that's fine, but you
should really give it up already trying to convince people SSP will
crack the earth.

FWIW, NO SSP == NO DKIM.  Its worth less overhead.

That said, Have a happy new year. :-)

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

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 30 Dec 2005 09:35:34 +0100

Douglas Otis wrote:

> This back-scatter problem can be resolved by implementing
> BATV at the cost of two additional wafer-thin packets.

Sorry, we just discussed "reputation", and that's completely
unrelated to SPF FAIL.  You can publish SPF policies without
any FAIL-qualifier at all, for white listing up to reputation
only SPF PASS is relevant.

"Simplified SES" (or whatever BATV is) is _more_ restrictive
than SPF:  In Keith's terminology it's a coordinated effort of
one MON (all MSAs) with its corresponding MRN (all MXs).  With
SPF you can aggregate several unrelated MONs (all "mail-outs").

Further BATV works only for "obvious" backscatter, as you said
in another article here it's essentially only for MAIL FROM:<> 
IIRC 3834 offers only a MAY for a MAIL FROM:<> in auto-replies.
Besides we're still far away from universal 3834 deployment.

BATV is a solution for a small part of the symptom of the real
problem, the fatal 1123 5.3.6(a) flaw.  Hardcore "bounces-to"
fans won't use BATV, they already hate the more flexible SPF.

BATV doesn't address the real problem, the forged Return-Paths.
Blocking 100% of all identified bogus bounces is nice, if you
can arrange things this way go for it, use BATV.  But it won't
help to block forged Return-Paths at the primary victim.  Some
of those spams reach existing users, they are not all bounced
to their forged Return-Path.

With SPF FAIL this crap can be rejected a.s.a.p. and not later,
SPF _fixes_ the design flaw in 1123 5.3.6(a) for those who want
it.  SPF is "back to the routes" (pun intended) as in the last
working SMTP model (STD 10).

Many RFCs, not only SMTP itself, also the DSN stuff and 3834,
depend on reliable Return-Paths.  You'd be forced to forget all
these features if you don't fix the cause:  1123 5.3.6(a) does
not work as expected in its own post-821 "bounces-to" world.

There are only two choices, SMTP without bounces etc., or SPF:
Absolutely nothing I've heard about offers to save the "good
bounces" from any MTA at or behind the first MX, only SPF FAIL
does this (originally Hadmuth's RMX idea).

> Unlike the (defunct) SPF scheme aimed at qualifying the
> return-path, BATV does not wait for wide adoption before
> benefits can be derived.

If you think that SPF is "defunct" you'll get SMTP without any
kind of auto-replies (not limited to bounces from MTAs outside
of your MON).  The SpamCop FAQ and AUP are more relevant than
say 2821 for this issue.

Besides SPF does not wait for wide adoption, it's good enough
if the professional spammers figure it out and avoid to abuse
SPF FAIL protected addresses.  That worked from my POV in 2004.

With BATV they might also get the idea, IFF their tests cover
a MAIL FROM:<> RCPT TO:<[email-masked]>,
and IFF that's the way how "call-back-verification" is supposed
to catch forged "BATV-protected" Return-Paths (?)

Compared with SPF "call-back verification" isn't cheap, and for
BATV the local parts of the Return-Paths would be different for
each mail (?).  You can't cache results, you can't integrate it
behind a simple SIQ interface.  Please correct me if that's
wrong, but MTAMARK + BLs + CSV + SPF should all work with SIQ.

                           Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Fri, 30 Dec 2005 18:57:04 -0800

> than SPF: 

With effort, a compatible syntax could be defined that would satisfy
everyone, hopefully with a draft that only includes essential syntax and
nothing more.  The BATV draft seems to be a good start.  Perhaps it can
be further simplified.

Could this satisfy both camps?

  <mode>=<glob>=<local-part>@<domain> 

I am not an author for either of these drafts, but this technique should
be formalized, with the use of the syntax promoted.

> Besides we're still far away from universal 3834 deployment.

There is no question that better conventions are needed when dealing
with auto-responses.  Conventions that limit the alternative to MAILER-
DAEMON@, instead of a null address could be helpful.  However, in
dealing with a legitimate provider where an auto-response is being
exploited, per RFC3834 3.3, these auto-response local-parts should be
specific to this purpose.  These addresses will also be evident by the
inclusion of the BATV tag in the RCPT TO, and could be introduced into a
BATV expectation list, when needed.  Anyone auto-responding with an
address used for other purposes would be taking risks in other ways.

> fans won't use BATV, they already hate the more flexible SPF.

This is not an issue for BATV.  BATV does not depend upon any third-
party adoption.  The domain implementing BATV benefits.  As part of the
BATV draft, when the message is delivered, removing the tag or
obfuscating the BATV <glob> section in what is normally prefixed as
"Return-Path:" would also be a helpful practice.

> BATV doesn't address the real problem, the forged Return-Paths.

On the contrary, BATV eliminates the forged return-path as a delivery
strategy.  Preventing this ploy is key, as the return-path should serve
no other purpose. 

> to their forged Return-Path.

Source identifiers should be used to exclude spam, rather than attempts
to verify the return-path, as this represents far less overhead and does
not alter existing practices.  Forged return-paths are often attempts to
side-step source filtering.  When either a DSN or auto-response is
expected, then BATV would be effective at eliminating illegitimate
messages and the "side-step" strategy.

> working SMTP model (STD 10).

"As Soon As Possible" is not better than "As Painless As Possible." : )

Rather than compiling lists of addresses for outbound servers for a set
of domains by issuing dozens of DNS lookups, BATV can thwart this
strategy with 2 extra TCP packets within a 6 packet exchange.  Just one
DNS lookup on average will exceed this overhead.  Being able to rely
upon source identifiers and BATV represents better protection with much
less overhead.  BATV, the painless "zero-lookup" protective
strategy. : )

> not work as expected in its own post-821 "bounces-to" world.

This is a problem only when a third-party attempts to verify the return-
path.  BATV changes this paradigm.  BATV allows the third-party to
concentrate on source identifier filtering rather than issuing call-
backs or other expensive techniques.

> does this (originally Hadmuth's RMX idea).

Prevent the bounce delivery strategy from being successful, and soon it
will not be used.  BATV prevents this strategy from being successful
without changing email practices.  SPF adds overhead and expects changes
to email practices before being fully effective.  What is worse, when
SPF is seen as "weak" authentication as with Sender-ID, then a new
problem arises.  Those who publish SPF records are at risk of being
block-listed when these records have been exploited. : (

> of your MON).  The SpamCop FAQ and AUP are more relevant than

When AV filtering produces a fair amount of bounce traffic, advocating
deletion of DSNs for domains without either an SPF record or a DomainKey
signature is an unfortunate reaction.  Even assuming this were good
advice, SPF records are open-ended and Domain-Key signatures are not
required to be within the same domain as the return-path.  These are
holes waiting to exploited when this stop-gap approach becomes more
predominate.  BATV can be a long term solution that better insures the
integrity of email delivery.

SPF qualifying the return-path is defunct as there are no records
defined for this purpose, with this record usurped by Sender-ID.  The
opt-out strategy still risks wholly unfair treatment.

> SPF FAIL protected addresses.  That worked from my POV in 2004.

This explains the hostility to RFC1123 5.3.6(a). 

> each mail (?).

With an adopted convention for BATV, the consistent local-part can still
be determined.  Call-back is not a good practice, but BATV can even
improve upon the security obtained by that use as well.

-Doug

---

From: John Leslie <[email-masked]>
Date: Fri, 30 Dec 2005 23:36:48 -0500

Nathaniel Borenstein <[email-masked]> wrote:
> ... I think most of us pretty much agree about the critical role of
> reputation.

   I've noticed a lot of what I call "lip service" about the critical
role of reputation. To say this differently, many folks seem to think
you can choose a "reputation system" almost at random, and it's sure
to improve your signal/noise ratio, "unless you've chosen the wrong one".
(which, I suppose, is a tautology...)

   But, in my view, we have no basis to choose the "right" one unless
we have a good understanding of what it measures and a workable idea
of how to "end run" when it falsely rejects good messages.

> the sources of messages.  Once we have that, we have the minimal
> data that a reputation system will require to be able to start
> doing something at least mildly useful.

   A lot depends on what we mean by "weakly authenticating".
   
   People who take security seriously always call the authentication
inherent in an established TCP connection "weak authentication"; but
in fact it represents a pretty-darn-good correlation. Thus blacklists
based on IP address alone have an excellent correlation to sending
SMTP clients which have, at some time, sent abusive email. (Their
problems lie elsewhere.)

   OTOH we have schemes running which don't claim correlation much
above 60%, and offer no assurance the correlation will remain that
high. These, IMHO, don't qualify as "useful authentication", but
it's hard to argue they fail to be "weak authentication".

> source) of incoming messages.

   I don't agree with Nat here.

   As a practical matter, _many_ folks will prefer sorting through
100 spams to losing one good email. I see darn little "market" for
anything which can't get it 99% right. What I think we're seeing is
folks that design a system for their own use, achieve an accuracy
of sorting sufficient for their needs, and offer it to others
because they see their marginal cost (per new customer) as
essentially zero.

   Further, until the "customer" abandons an existing method, the
barrier to adopting an additional method is pretty close to 99%
correct identification of email which passed the existing method(s).
This is _not_ an encouraging situation for entrepreneurs.
   
> To some extent, there's a chicken-and-egg problem with
> authentication and reputation technologies.  My hope for DKIM
> is that it will give us one good enough egg to produce a chicken,
> which can then (in much the manner that Cain and Abel found their
> wives, I guess) facilitate a whole new generation of authentication
> technology eggs.

   I find the challenge of designing a reputation system based in
DKIM a bit overwhelming. DKIM offers assurance that a domain has
"taken part in the transmission of an email message" containing
certain headers (which the recipient probably never sees), but no
assurance that anything else hasn't been changed since then.
There's no assurance that the message isn't a replay attack, nor
is there assurance that the original hasn't been lost. This is _not_ 
an attractive base upon which to build reputation.

>> identifier, innocent email-address domain owners will be
>> seriously harmed. Abusers will find acceptance methods for an  
>> authorization scheme.

   Doug is complaining about the difficulty of designing a useful
reputation system on such a base. I entirely agree with him there.

   But I wish it to be clear I am not complaining about reputation  
services being out-of-scope in the DKIM charter. I prefer it that   
way: otherwise I'd be facing a serious challenge trying to cobble
on a useful reputation heuristic, with really no hope of meeting
the charter deadlines.
   
   I'm really not complaining at all: I'm just trying to bring
some sense of reality to what we should expect of DKIM-based
reputation systems.

> need to understand
> A) the role of "weak authentication" (weeding out some but not
>    all of the bad guys at any point in time, and using multiple
>    sources of information to judge the desirability of a message)

   Expressed this vaguely, there's nothing to "understand". We'd
need useful estimates of what fraction of "bad guys" will be weeded
out and what fraction of "good guys" are (wrongly) weeded out. I'm
not sure any useful estimates of that can be found.

>    and
> B) the need for a continually evolving set of (ever-stronger,
>    we hope) mechanisms for proving that a message is desirable
>    to the recipient.
 
   This sounds like a research project. As a research project, I 
heartily favor it.

--
John Leslie <[email-masked]>

---

From: John C Klensin <[email-masked]>
Date: Sat, 31 Dec 2005 18:49:53 -0500

--On Tuesday, 27 December, 2005 10:33 -0500 Nathaniel Borenstein
<[email-masked]> wrote:

> The word "only" makes me cringe a bit in any discussion like
> this (a global fascist state, for example, is another possible
> critical role of reputation.  I see the cycle as going like
> this:  We need at least one standardized, moderately-useful
> system for weakly authenticating the sources of messages.
> system will require to be able to start doing something at
> least mildly useful.  Once we have *that*, we will have (in
> our reputation systems) a built in "market" for additional
> systems for (perhaps less weakly) authenticating the
> desirability (not necessarily solely due to the source) of
> incoming messages.  To some extent, there's a chicken-and-egg
> problem with authentication and reputation technologies. 

Nathaniel,

I've held off responding to this because people assume that I'm
an opponent of either DKIM or of chartering a WG for that
purpose, and I'm neither.  However, the comment above calls for
a response or two.  John Leslie has provided part of that
response; let me provide the other part.

Global reputation vetting is a hard problem.  To a considerable
extent, that makes a strong argument for local reputation
assessment, not for identifying those who cannot be
reputation-validated as spammers but for giving preferred
treatment to those who are on some preferred list.  As I
understand it, that is a major motivation of at least several of
those who are pushing DKIM.  So far so good.

The difficulty is that establishment of such a mechanism makes
it very easy for, e.g., an ISP that wants to "protect its
customers from spam" and reduce spam traffic on its backbone to
say "aha, any message that isn't validated/authorized by someone
whom we recognize is obviously hostile and should be silently
dropped".  And the only sources they are likely to recognize are
members of their own messaging cabal.   In theory, the
marketplace should fix that problem --all of their customers who
actually want to received email from customers of other ISPs
would leave.   But, in practice, we know that those marketplace
mechanisms often don't work terribly well.   I would be hesitant
to make comparisons between that situation an global fascist
states, but, since you introduced the term...

Now using DKIM, or a wide variety of other techniques, this way,
would clearly be abuse of the intent of the methods.  But one of
the things we all should have learned by now is that a
technology that can be abused almost certainly will be abused.
It seems to me that, were DKIM to succeed, we would run a
significant risk of seeing the Internet fragmented into
DKIM-approval camps (with the non-DKIM-users left out of all of
them).  And if it produces, as you suggest, a new generation of
authentication technology eggs, that could lead to even more
fragmentation as various parties are forced to choose between
the costs of supporting multiple methods and the risk of
receiving only that mail that comes from someone who has chosen
the same method as the receiver and the receiver's ISP and
environment.

That situation could lay an egg indeed.

Again, this is not an argument against chartering a WG.  It
might be an argument for insisting that such a WG explain, as
part of proposing something for standardization, how obvious
abuses of it are to be avoided or repelled.

     john

---

From: John Levine <[email-masked]>
Date: 1 Jan 2006 04:35:14 -0000

I hope the message here is not that we should restrict ourselves to
developing technology that is idiot-proof, since a sufficiently
determined idiot, of which there are many, will do idiotic things with
any technology that we never in a million years would have
anticipated.

However, ...

>members of their own messaging cabal. ...

People have been building e-mail walled gardens as long as there has
been e-mail.  Fifteen years ago there were lots of disjoint mail
systems, none of which remain except perhaps as gateways to the world
of SMTP mail.

One favor that the SPF crowd did for us was to give the aforementioned
idiots a chance to find out what a bad idea it is to reject mail
arbitrarily from people who don't jump through their hoops, so nobody
rejects for SPF failure any more.  People who use C/R against people
not on their whitelists have found the same thing -- they all check
the folder of unconfirmed mail because they know there's lots of real
mail from people who won't hoop jump.

If the idiots were to latch on to DKIM and start rejecting valid mail,
like they have to the past umpteen magic bullets, why do you expect
the results to be any different?

R's,
John