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

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Dec 2005 17:04:47 -0800

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

-Ekr

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

---

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

Hi Eric,

> shouldn't be effectively prohibited by charter from making incompatible

I don't read that as prohibiting incompatible changes, since
canonicalisation and hashing are two such changes. Incompatible 
improvements that are not bug-fixes are discouraged though, and
I can see how that raises concerns. I can also see how apparently
encouraging incompatible improvements that are not bug-fixes
raises concerns.

Personally, I think each on-the-face-of-it-reasonable suggested
improvement has to be considered, but the more time passes and
the more the specifications are mature, the higher the bar is
raised. Since these specs. have been around a while and have
been implemented it seems reasonable to start this WG with a
higher bar than one where neither of those things are true. Its
obviously tough to write text saying the above that makes everone
happy since there are so many subjective aspects involved.

Clearly though (as pointed out) a new "rough consensus" has
to be established in the WG, and subsequently during IETF last
call and I do expect that process to involve questioning the
design decisions which were made prior to the WG getting
started. Whether such questioning results in changes
(compatible or otherwise), is something we can't know at this
stage.

I'd also note again that "compatible with what's deployed"
doesn't (once you've changed canonicalisation, which has
happened already) mean the same as on-the-wire compatible, so
the current text is actually less constraining than might
seem to be the case at first reading.

Lastly, the text does say that the working group will not
be unreasonable in attempting to maintain compatibility, so
as the Marx brothers said, there is a sanity clause after
all:-)

Basically, I think the current text is ok, even if it
looks a bit scary.

Stephen.

---

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

> shouldn't be effectively prohibited by charter from making incompatible

I hear you, Eric, and, yes, we've all discussed this at length before.
There are people with opinions at both extremes on this (from "we must
leave that paragraph unchanged" to "we must remove that paragraph
completely").  For my part, as the current editor of the charter, I'm
happy with a change in the text if we can get consensus on some text
that will make both sides at least somewhat happy (or perhaps I should
say "somewhat less unhappy").  We weren't able to do that on the ietf-dkim
list before the BOF.  Let's try to spend a little time doing that now
(keeping in mind the realities of the IETF process, and that the charter
can not bypass that process, nor is it trying to).  We have more eyes
and more fingers now, and perhaps someone new can craft text that will
work.

Experience in this area (anti-spam-related things) shows us that we DO
need strong guidelines to stay on track, and I believe that weakening the
wording too much does not provide us with those guidelines.  As I said in
in my other post, just sent, it's really the job of the WG chairs to deal
with this.  Still, strong guidelines make it easier for the chairs to do
their jobs efficiently, and for the ADs to handle escalations effectively.

Can someone propose an alternative to the first-quoted paragraph above,
from the proposed charter, that keeps the sense that the specifications
we're agreeing to use as a starting point be strong conflict-resolution
guides, and that they be used to steer the discussion... without making
it seem, incorrectly, that the WG is not willing to accept changes that
make sense to make?

Barry

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

---

From: Tony Hansen <[email-masked]>
Date: Wed, 21 Dec 2005 09:07:08 -0500

I would be happy with the text that was used in the xmpp charter:

	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.

This text still keeps the bar high for unnecessary changes, was already
vetted through an existing charter, and helped us through a similar
impasse when xmpp was chartered.

	Tony Hansen
	[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Wed, 21 Dec 2005 11:38:53 -0800

>impasse when xmpp was chartered.

I agree with Tony on the benefits of re-using this language, and it certainly works for me.

I'd also like to thank Stephen Farrell for pointing out the overview document as a logical place to answer the relationship to other IETF technologies questions.  The current language for that work item says:

> An informational RFC providing an overview of DKIM and how it can fit into
>overall messaging systems, implementation and migration considerations, and
>outlining potential DKIM applications and future extensions.

I suggest adding "how it relates to other IETF message signature technologies". Given that this document already discusses other potential DKIM applications and future extensions, Stephen is right that the discussion fits here better than either place I earlier suggested.

			regards,
				Ted Hardie

---

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

> say "somewhat less unhappy"). 

Consensus on the charter would of course be a good thing, but it's not a
necessary condition.  The job of the charter is to appropriately direct
and focus the group's work, not to make everyone happy.  

Also, the WG may draft a charter, but the charter isn't something that
has to be settled on my the WG.

Keith

---

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

> higher bar than one where neither of those things are true.

I strongly disagree.  Implementation of a draft specification is useful
to establish a proof-of-concept and perhaps (especially if there are
multiple independent implementations), to unconver potential
ambiguities in the draft specification.  Implementation is not however
a good indicator of protocol soundness.  This might have been
sufficient in ARPAnet days, but on the scale of today's Internet it is
necessary to perform extensive analysis and review - neither of which
have been done for DKIM.

So no, it's not appropriate to raise the bar for changes on the basis
of existing DKIM implementation.  At most, the charter should specify
that new DKIM signatures be distinguishable from signatures made
according to the old DKIM specification.

Keith

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 Dec 2005 22:17:34 +0000

> it certainly works for me.

Me too FWIW.

Stephen.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 21 Dec 2005 18:36:27 -0500

> I agree with Tony on the benefits of re-using this language, and it certainly works for me.

Then it sounds like we have some text that we can compromise on.  Jim
Fenton has already said that this text covers his concerns about as well
as what we had, Stephen Farrell has accepted it, and now I'm weighing in.

I suggest that the IESG replace that paragraph in the proposed DKIM
charter with the paragraph above, and that we move on from this topic
to any others that need to be dealt with.

Barry

---

From: Dave Crocker <[email-masked]>
Date: Wed, 21 Dec 2005 15:59:00 -0800

Fellow DKIMers,

 > to any others that need to be dealt with.

Well, I guess no one else is concerned about the sequence that has just 
taken place.

We carefully develop charter language through two, complete, multi-month 
rounds of open collaboration, including significant focus on exactly the 
language in question, both times.

Some folks come in at the late stage of the second open process and seek 
to change this text, but they fail to develop support.

So they re-assert their concerns again during the IETF charter last 
call, and now the chairs quickly concede the change, even before getting 
support from the rest of the group.

It's not that the proposed language is bad, it is that this sequence 
bodes rather poorly for dealing with further demands from folks who fail 
to gain support.

And it does not help that two of those doing the (re-)demanding are area 
directors and another an IAB member, raising the fear that the current 
concession is strictly to appease the authority those folks have.

All this with no specific technical concerns driving the demand.

d/

-- 

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

---

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

>> I agree with Tony on the benefits of re-using this language, and it 

It does not work for me.  It is biased in the wrong direction.  It is 
entirely inappropriate to encourage the WG to produce output that is 
compatible with a specification that is known to have significant flaws.

Consider also the following:

a) we already know that incompatible changes are necessary, thus 
verifying software will need to be upgraded

b) as DKIM is specifically NOT intended to provide assurances of message 
authenticity for more than a few days, compatibility with existing 
signatures is of little consequence anyway

> to any others that need to be dealt with.

I suggest the IESG replace the paragraph with the following:

While it is understood that the WG will use the current DKIM 
specifications as a starting point, the WG is neither expected nor 
constrained to specify a standard which is compatible with those 
specifications.  The WG should feel free to make whatever changes are 
necessary to produce a specification that is robust with respect to the 
requirements and flexible enough to support a diverse set of usage 
scenarios.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 21 Dec 2005 23:13:05 -0500

Dave Crocker wrote:
> and now the chairs quickly concede the change, even before getting 

'scuse me; it seemed to me that Tony Hansen and Jim Fenton counted as
some of the rest of the group.  It also seems to me that no one has made
me the boss, so what I suggested was just that: a suggestion.  You may
feel free to spend more time arguing about that paragraph if you like.
My opinion (and that's all it is) is that that's not useful.

I understand the principle you're fighting for, Dave.  And I think it
will come up again, which is why you're fighting it.  I think it will be
better to fight it later, if necessary.

Barry

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 22 Dec 2005 06:46:07 +0100

Tony Hansen wrote:
 
> I would be happy with the text that was used in the xmpp
> charter

+1
  
And <http://permalink.gmane.org/gmane.ietf.dkim/1568> is no
strong objection, or is it ?
                            Bye, Frank

---

From: Dave Crocker <[email-masked]>
Date: Wed, 21 Dec 2005 23:43:31 -0800

Barry,

> will come up again, which is why you're fighting it.  

ack.

> I think it will be better to fight it later, if necessary.

It always seems that way, at the time.

d/

-- 

  Dave Crocker

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 21 Dec 2005 23:54:56 -0800

We have had three proposal for some text on changes to prior work, the
current proposed charter, the text from the XMPP charter, and the text Keith
provided below.

The question that I think IESG should be asking themselves is how is this
similar and/or different from other groups the have chartered or will in the
future. Nearly every group has some people with a fairly strong idea of at
least one way to solve the problem. Without this, it is usually not clear
the work is even possible. Now some groups, XMPP for example, perhaps TLS
long ago, have substantial deployment with difficult backwards compatibility
questions - theses situation might require the charter to provide more than
normal limitations to the scope of the solutions that are possible. I'm
failing to see that dkim has existing deployments or difficult backwards
compatibility problem that would cause the need for some special text in the
charter more than you average WG. (They do have difficult backward
compatibility problems with existing email systems and I like the text that
limits the scope on that.) My current understanding is that the deployments
are small enough that changes are still easy and that non backwards
compatible changes are already expected. I fail to see the analogy to XMPP
but perhaps there is a good reason for something more like XMPP. I'd sure
want whoever approved this charter to be able to give me a clear reason why
they though this WG would produce better work by having this constraint.
It's going to set a precedent for things to come.

Practically speaking, I'm not sure it will make much difference to the work
that the WG produces. If the individuals that will form the WG feel that the
WG has consensus that they will not make changes beyond a a certain
boundary, they don't need the charter to set that boundary. The strong
arguments that this needs to be in the charter makes me wonder if the
individuals that will form the WG will agree to very limited changes or not.
If they will, it's barely worth arguing for here.

Related to how much the charter pre-supposes the solution, the sentence that
"Public keys needed to validate the signatures will be stored
in the responsible identity's DNS hierarchy." seems like a pretty heavy
constraint on the possible solutions and one that some proposals disagreed
with. 

I'm not arguing against the current dkim drafts, I am arguing that the
future of doing internet drafts should not be a process where we come to
agreement in a dark and smokey room with a small group of people then set up
WG where effectively only syntax level changes can be made. If we like these
drafts as is, let's skip the WG and just take them forward as AD sponsored
individual drafts and call it done, if we think we need a WG, allow it to
have change control to select a reasonable solution to the problem.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 22 Dec 2005 09:51:58 +0100

Branching off from the interminable "justifiable changes" thread....

--On onsdag, desember 21, 2005 23:54:56 -0800 Cullen Jennings 
<[email-masked]> wrote:

> Related to how much the charter pre-supposes the solution, the sentence
> that "Public keys needed to validate the signatures will be stored

I think this is part of "divide and conquer" that is generally argued to be 
an useful strategy in the IETF: once we buckle down and start writing 
specs, we're documenting one approach, with one set of advantages and 
disadvantages, and are trying to prove that *this approach* is feasible. We 
did that to (I believe) OSPF, IPNG after the "pick one" round, PKIX (vs 
SPKI), IM when it was split into SIMPLE and the 2 alternatives (with XMPP 
being a late 4th) and so on. Each of these groups could regard the "what 
are the alternatives" question as out of scope.

I think that's a good way to get things out the door in a reasonable 
timeframe; I also think that the IETF at the moment lacks venues for the 
(probably interminable) discussions about what approaches to a problem 
exists and whether there are non-chartered alternatives that are worth 
following up - but I think the approach of chartering a WG to look at one 
and only one approach is a reasonable one.

                 Harald

---

From: Keith Moore <[email-masked]>
Date: Thu, 22 Dec 2005 08:27:43 -0500

>> constraint on the possible solutions and one that some proposals 
>> disagreed with.
> 
> I think this is part of "divide and conquer" that is generally argued to 
> be an useful strategy in the IETF: once we buckle down and start writing 
> disadvantages, and are trying to prove that *this approach* is feasible. 

Sometimes feed-forward _is_ useful, and I would agree that the use of 
DNS to store public key information is one of the fundamental 
assumptions behind DKIM.  Change that assumption and you will probably 
produce a system with very different characteristics than DKIM is 
currently assumed to have.

OTOH, the assumption that _all_ public keys used to validate DKIM 
signatures will be stored in DNS is a very limiting one, because it 
appears to lead to either

a) a constraint that policy be specified only on a per-domain basis 
(which is far too coarse for many domains) or

b) a situation that large numbers of DNS queries may be required to 
validate a single signature

I'm comfortable with having a domain's "root public keys" stored in DNS 
but allowing the corresponding "root private keys" to sign key 
certificates for "individual public keys" that can be included in 
DKIM-signed messages.  The policies for use of those public keys can 
then be encoded in the certificates, allowing those policies to be 
specified on a per-user basis.  This gets out of the trap of having to 
specify policy on a per-domain basis, and doesn't require any more DNS 
queries than current DKIM.  IMHO it would make DKIM much more flexible 
and adaptable to diverse domain situations (and thereby much more 
acceptable as a standard) than the current proposal.

Keith

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 22 Dec 2005 13:40:26 +0000

Keith,

> acceptable as a standard) than the current proposal.

If there were an I-D describing such a protocol, I'd be interested in
reading it - is there one?

Stephen.

---

From: Keith Moore <[email-masked]>
Date: Thu, 22 Dec 2005 08:47:13 -0500

> charter more than you average WG.

The need for special text is not due to existing deployments or 
backwards compatibility problems; it is due to the existence of a small 
number of individuals who have a history of arguing quite forcefully 
that certain design decisions are carved in stone, despite the problems 
caused by those decisions and the lack of any working group consensus on 
  those decisions.  Said individuals have also been known to make 
misleading statements to support their arguments.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 22 Dec 2005 08:49:03 -0500

> reading it - is there one?

Not yet.  But it hardly seems like the time to write an I-D when there 
is at present considerable effort being invested to preclude such an I-D 
being considered by the group.

Keith

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 22 Dec 2005 07:48:11 -0600

> Branching off from the interminable "justifiable changes" thread....

Dropping DKIM, because those people suffer enough without being subjected to 
more general discussion about the nature of the universe at IETF :-)

I applaud Cullen for his note. I agree with the parts that Harald snipped 
out, too (I'm just trying to post below the thread branch, so followups stay 
together).

> and only one approach is a reasonable one.

The analogy I've been using in private e-mail discussion on how new work 
comes into the IETF is that the IETF is a bakery that's become pretty 
difficult to enter with only a bag full of raw ingredients, but if people 
bring in a finished cake with frosting and just ask for a boz to put the 
cake in, we're not a bakery any more.

It really is a problem that (as Harald says) we don't have a good place to 
discuss alternative solutions, given that we are trying to be an engineering 
task force that may also standardize protocols, not a protocol 
standardization task force that occasionally tries to engineer something. 
People who need to solve a problem have every incentive to deploy what they 
believe is a solution to their problems as soon as they can specify it. The 
more specification work that happens on the way to the IETF, the more likely 
that work is to be deployed while we are discussing charters, the more 
pushback we see on charter discussion, and the less likely a second-round 
version of the protocol is to be widely deployed.

I'd also like to point to Thomas Narten's draft on "how to run a successful 
BOF" (currently 
http://www.ietf.org/internet-drafts/draft-narten-successful-bof-00.txt). I 
would like to see some changes considered for the way we bring new work into 
the IETF, but getting a baseline on how it works today is a critical first 
step. I have provided a page or two of comments to Thomas, CC: Brian as 
General AD, and hope that others also look it over and provide feedback 
(soon)

Thanks for reading,

Spencer

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 22 Dec 2005 07:59:16 -0600

> Said individuals have also been known to make 

I'm thinking we must be coming to the end of productive discussion...

Spencer

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 22 Dec 2005 06:35:47 -0800 (PST)

On Thu, 22 Dec 2005, Keith Moore wrote:

> Sometimes feed-forward _is_ useful, and I would agree that the use of DNS to 
> store public key information is one of the fundamental assumptions behind 
> DKIM.  Change that assumption and you will probably produce a system with 
> very different characteristics than DKIM is currently assumed to have.

Not necessarily. One of the proposals that went into DKIM had characteristic
of storing public key fingerprints in dns. This seems quite close to DK but
has a number of advantages and unlike DKIM or DK does not put serious extra
pressure on DNS infrastructure - which while very capable of serving data 
like ip addresses (i.e. fixed size small data) would not work so well for 
when data served & answer would either come close to or exceed 512bytes 
UDP limit.

But fingerprints (hash of public key) are finite and small pieces of data
that are the same size no matter of public key size has to be larger or
smaller and with this size being close to that of ipv6 address. Additionally
having public key available with a message brings some additional advantages
and allows for optimized algorithms during verification.

As I noted the group forcefully removed considerations of such alternatives
based on the charter and I consider this to be a disadvantage to community.

> OTOH, the assumption that _all_ public keys used to validate DKIM signatures 
> will be stored in DNS is a very limiting one, because it appears to lead to 
> either
>
> a) a constraint that policy be specified only on a per-domain basis (which 
> is far too coarse for many domains) or
>
> b) a situation that large numbers of DNS queries may be required to validate 
> a single signature

Its rather likely that it would lead to both.

> I'm comfortable with having a domain's "root public keys" stored in DNS but 
> allowing the corresponding "root private keys" to sign key certificates for 
> "individual public keys" that can be included in DKIM-signed messages.  The 
> policies for use of those public keys can then be encoded in the
> certificates, allowing those policies to be specified on a per-user basis.

You can just use X.509 certificates and retrieve them from HTTP with SRV
records being used to confirm location of domain's root certificate. That 
walso one of the other alternatives (and the one I used for my proposal)
and yes, it does make it much easier to do per-user policies & signatures.

> This gets out of the trap of having to specify policy on a per-domain basis, 
> and doesn't require any more DNS queries than current DKIM.  IMHO it would 
> make DKIM much more flexible and adaptable to diverse domain situations (and 
> thereby much more acceptable as a standard) than the current proposal.
>
> Keith
>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 22 Dec 2005 10:32:55 -0500

> (which is far too coarse for many domains) or

Actually, the DKIM base spec does provide a mechanism for replacing the
DNS keystore with something else.  Look at 1.4 for a general statement,
and the description of the "q=" tag in 3.5.  DKIM's intended to be able
to support user-level keys in a future version (there's some discussion
of that in appendix A), and its design is set up specifically not to
prevent that.

The proposed charter puts the details of other key management systems
and user-level keys out of scope so that we can contain the work at this
stage, and make quick progress on the first version.  It'd be entirely
reasonable to recharter and attack these issues immediately after
completing the first round of chartered work, if there are enough people
who want to work on that.  Or we can see how a while of deployment goes,
and form another WG in a year or so to do it.

Barry

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 22 Dec 2005 07:45:02 -0800 (PST)

> of that in appendix A), and its design is set up specifically not to

The spec basicly says that you must support DNS public key distribution
and authorization; that something else may also be added later will not 
change requirement for pki in dns and will only be usefull for those
who can support it as alternative way to retrieve the key (which means
the key would still need to be made available through dns for those who
do not).

It is really no brainer to see that if we have several authorization 
meachanisms a set of them would have to be done as a required for those
creating implementation in order for them to be used and that means 
working on all that as part of the main work on the system and
releasing together with other documents on the signature system.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Thu, 22 Dec 2005 11:38:44 -0500

> and form another WG in a year or so to do it.

I disagree.  The first standard version of DKIM needs to be something
that is broadly applicable, not something that just handles a few
corner cases.  The amount of stress associated with getting closure and
consensus on a document is sufficiently large (independent of the
document scope) that it doesn't seem like a good idea to waste all of
that effort producing a first document that is of limited applicability,
and that will need to be updated soon - particularly when a lot of the
division within the group stems from the current DKIM spec's
overconstraining the problem.   

If your goal is gaining consensus on a useful specification in the
shortest amount of time, it makes far more sense to work on the
different aspects of the problem in parallel rather than serially.  
Let one subgroup work on per-domain keying, key management, and
policies; another subgroup work on per-user keying, key management, and
policies; another subgroup work on message canonicalization; another
subgroup work on specifying signature and hash algorithms (and managing
the transition from weaker to stronger algorithms as these are
discovered); and finally, have a coordination team responsible for
making everything fit together and managing the framework (definitions,
header field names,  parameter names, keywords) that all of these
pieces fit into.  Give each subgroup a year, with deliverables at 4
month intervals.  After a year, expect to do working group last call on
all pieces and start polishing the drafts for final publication.  If
any piece proves to be unworkable, it can be thrown out after a year.
But even if that piece needs to be replaced from scratch and this
causes a delay that's better than imposing a serial dependency a
priori.  The unworkable piece could as easily be per-domain keying as
per-user keying.

I believe this approach will produce a consensus far more quickly than
the serial approach, and that the resulting standard will be more
broadly applicable and more robust.

Keith

---

From: Michael Thomas <[email-masked]>
Date: Thu, 22 Dec 2005 08:55:55 -0800

Cullen Jennings wrote:
> My current understanding is that the deployments
> compatible changes are already expected. 

Mail is, in fact, pretty different than most IETF protocols
insofar as it's a store and forward system where there can
be no expectation of end to end negotiation which is generally
helpful for smoothing out protocol botches and incompatible
changes. With mail every time you make an incompatible change,
you have to hope that the receiver at the far end is in synch
with that incompatible change or you're pretty well hosed. With
each one the utility of the protocol is divided and conquered.

I'm not sure who Keith was talking about with his broad brush
assertion -- there are probably about 30+ people who've had
a hand in the creation of the current drafts before we ever
brought it to IETF, but my concern is that given complete
lattitude the resulting thrashing around will produce an
extremely narrow intersection between compatible senders
and receivers. Which will constitute failure in all likelihood.

On the other hand, I think its really a stretch to say that
we are unwilling to listen, or that we're looking for a rubber
stamp. We have already agreed to -- and incorporated -- a
substantial backward incompatible change (the canonicalization)
due to feedback (and threats) we got. What I'm hoping for
is that there is a sufficiently high barrier that cosmetic
changes not be good enough reason to make a backward incompatible
revs. Equally disasterous would be to throw this entire area
open for a greenfield design; considerable time and effort
has been expended, and frankly Keith's observations don't
strike me as new or novel -- we've been at this for many
years at this point, and his points have been hashed and
rehashed many times over the years by the people who have
been paying attention to this more than just the week
before and after a BOF.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 22 Dec 2005 10:17:58 -0800

Michael,

Nice note.

One point, however:

Michael Thomas wrote:
>  We have already agreed to -- and incorporated -- a

We have agreed to the addition of an enhancement that provides a good 
alternative to the existing set of two algorithms.

That is quite different from tossing out over-the-wire backward 
compatibility.

I have not seen the group agree that a sender of an (ESTG) DKIMv1 
signature will fail with an (IETF) DKIMv2 validator.

d/
-- 

  Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Thu, 22 Dec 2005 10:37:29 -0800

>strong objection, or is it ?
No, it's not an objection to the text used in the xmpp charter.  Thanks
for asking.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Thu, 22 Dec 2005 11:00:27 -0800

> signature will fail with an (IETF) DKIMv2 validator.

Dave,

'nowsp' canonicalization does not exist in "DKIMv2" (-base-01).  It was
eliminated, rather than deprecated, because it created a vulnerability. 
While some -base-01 verifiers may implement legacy nowsp support, a
fully compliant -base-01 verifier may not work with a -base-00 signature
that uses nowsp canonicalization.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Thu, 22 Dec 2005 11:13:36 -0800

> different aspects of the problem in parallel rather than serially.

My concern regarding the charter is related to inclusion of the SSP  
draft, which can impose significant disruption.  In my view, DKIM  
should be seen as aspect of the SMTP transport.  Having a signature  
at the transport qualifies sources of email, but should not constrain  
use email-addresses.  Schemes related to the email-address such as S/ 
MIME or OpenPGP are designed to support email-address limitations.   
On the other hand, DKIM purports to offer S/MIME or OpenPGP like  
features for a sub-set of domains willing to disrupt normal email  
practices.

The premise for DKIM protection assurances is based upon visual  
examination of the email-address.  This seriously flawed concept  
already demands most MUAs change.  Even the body-length option pre- 
supposes there is some type of MUA modification.  With DKIM sans SSP,  
the MUA would be able to recognize prior correspondents without any  
other exchange of information.  In some cases, an MTA could use this  
recognition to exclude some abusive traffic based upon prior  
recognitions.  The MUA should be able to safely signal source  
recognition, but signaling adherence to some authorization would only  
place recipients in peril.

SSP, just as with Sender-ID, requires email-address domain owners  
authorize the source of their email, where signatures are transposed  
for address lists.  To allow existing practices, open-ended  
authorizations are required.  The danger from this approach has been  
made apparent by those willing to hold any sort of authorization  
accountable for abuse seen.  There can be no promise that  
authorizations can be open-ended to support existing practices.   
Reputation schemes bolstered by having "authenticated" the identifier  
when finding an authorization record will quickly preclude use of  
open-ended authorizations.

When only a few domains publish the closed-ended authorization  
records for SSP, looking for policy for the majority of email will  
then require that label trees be climbed, where none of this effort  
can be effectively cached.  The solution for this rather broken  
strategy is to create records that indicate open-ended authorizations  
to mitigate the search.  These nonsense open-ended records however  
expose the email-address domain owner to unfair reputation schemes  
already in place.

Details have been published for "compatible" extensions to DKIM that  
improve upon source recognition, abating abusive message replay,  
locating compromised systems, limiting the number of signatures per  
message, establishing expectations for specific email-addresses being  
signed, without requiring any additional lookups in most cases.

http://www.sonic.net/~dougotis/id/draft-otis-dkim-options-00.txt

The WG should be limited to establishing the base DKIM signature.   
This signature should be viewed as an aspect of the SMTP transport to  
differentiate it from S/MIME and OpenPGP.  Another WG should make  
efforts related to the MUA incorporating the protections offered by  
DKIM in an opportunistic fashion.  In essence, everyone becomes their  
own certificate authority based upon individual email source  
identifiers offered by DKIM.  Recipients would be able to confirm the  
validity of the correspondent through out-of-band identifications of  
the source.  This could be simply an expected confirmation when  
initially establishing a relationship.  Once the initial identifier  
has been accepted by the recipient, messages could be safely  
highlighted as coming from a recognized source.

There can never be a safe indication based upon a domain used in the  
email address as having authorized the message.  There must be more  
consideration given for the use of unicode.  One only needs to  
investigate the number of look-alike characters in Chinese to  
understand the fallacy of that assurance.  Even the individual that  
does not understand the difference between online.bigbank.com and  
online-bigbank.com could be protected by a recognition scheme.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Thu, 22 Dec 2005 11:20:30 -0800

> eliminated, rather than deprecated, because it created a vulnerability. 

sorry. i had misunderstood that line of discussion.  and, yes, 
vulnerability counts as a showstopper.

ack.

that still leaves useful over-the-wire compatibility, doesn't it?

d/

-- 

  Dave Crocker

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 22 Dec 2005 21:06:42 +0100

Douglas Otis wrote:

> DKIM should be seen as aspect of the SMTP transport.

IBTD.  Trying to find any feature in DKIM not covered by the
existing SMTP schemes (MTAMARK, CSV, SPF, but not PRA) it's
_independence_ of SMTP that fascinates me in DKIM.  All you
need is the header, a piece of software, and DNS.  It could
also work for news if we get the FWS canonicalization right.

> Schemes related to the email-address such as S/MIME or
> OpenPGP are designed to support email-address limitations.

Maybe they missed the point, mail without signature.  A simple
way to publish that all mails claiming to be from X are spam
if they don't have X's signature.  [ I'm just spamcop-ping 36
phishes claiming to be from my bank, hilarious ]

> SSP, just as with Sender-ID, requires email-address domain
> owners authorize the source of their email

At least we now have a complete list of traps and pitfalls for
that idea.  If all else fails we could "SSP" the Message-IDs,
or I'd try to understand your fresh "DKIM options" draft. <g>

                              Bye, Frank

---

From: John C Klensin <[email-masked]>
Date: Thu, 22 Dec 2005 15:35:05 -0500

Michael,

Since I believe that, whatever else happens, it is better than
those who are interested in DKIM get on with the work rather
than spending more weeks or months splitting procedural hairs,
let me see if I can explain the distinction I see. 

For context, I have a skeptical view of all spam-reduction
techniques that are based on giving the recipient better ability
to distinguish between good (or favored, or safer-than-most)
messages from less-good or actually-bad messages by
identification or classification of the point or origin (whether
by person, by domain, by address range or routing, etc.).    So
I am not, in any way, opposed to DKIM because I favor some
slightly-similar method; I'm almost equally skeptical about all
of them, but believe that any plausible ideas are worth serious
exploration.

That said, I see three reasonable ways to pursue work in the
IETF and a possible fourth:

	(1) One arrives with a more or less specific topic, and
	probably some ideas, gets an ordinary WG chartered, and
	then sorts things out and tries to end up with a
	standards-track document.  This approach assumes that
	_all_ issues that fall within the problem definition in
	the charter are on the table, even though a sensible WG
	will prune options as quickly as possible.  But any
	input that arises from pre-WG efforts is input, as if
	from a design team, and not binding on anyone, whether
	the design team (or other prior work) has consensus or
	not.
	
	(2) One arrives with what is, in essence, a finished
	product, ideally with claims of implementations,
	interoperability, and general soundness.   Taking such a
	product to a WG is a waste of everyone's time.  One
	takes it to the IESG, convinces them and the community
	that the work is appropriate for the IETF and as sound
	as you think it is, and get a four-week last call for
	standards track issued.
	
	(3) One arrives with an approach that needs exploration
	and exposure to the broader community.  One gets a WG
	chartered to explore that particular approach, but with
	the target of producing experimental and informational
	RFCs that document the approach and its apparent
	strengths and weaknesses.  Only after that process is
	completed and the agreed-upon specification (not some
	earlier version with some ideas about changes
	pre-standardization)implemented and tested in "live"
	situations is there a discussion about standardization.
	That discussion would presumably take the second path
	above unless there was still controversy about "best"
	solutions.  In the latter case, if the IETF decided
	there was a reason to try to pick, we would probably
	need a WG to explore that, but its charter would be far
	different from a WG intended to do design, as in (1)
	above.

In addition, there is, I think, one other approach that might be
appropriate, but only in very limited circumstances.  That
approach applies where there is a well-thought-out approach with
design team consensus, evidence of implementation, and no
clearly-identified technical concerns.    Then, and only then, I
think that an approach of "the WG gets to challenge the base
spec and assumptions, but to change them only if there is good
reason and consensus to do so" is plausible with a standards
track target.  I think that XMPP, and the XMPP language,
probably is an instance of that case.

Now, for DKIM, there have been claims that it is widely deployed
and successful but still needs IETF consideration.  If that is
the case, it would, by my typology, fall in the fourth category
(but with an XMPP-like constraint, not the much stronger prior
decision that seems to be implied by the current text.    I
think it has also been claimed that it is sufficiently finished
and mature that IETF ratification and endorsement is needed, but
no real changes are required or desirable.  If that is the case,
then the second option above would seem to be the right one.
Others have claimed that there are known, and serious, technical
deficiencies.  If they are correct, then it seems to me that the
only reasonable possibilities are the first or third options,
i.e., either "no restrictions" or "not standards track at this
point".

Other than claims and counterclaims, I've seen little that would
permit the IETF community to form a consensus about exactly what
stage the DKIM work (and implementation, deployment, and
demonstrate that it accomplishes whatever is being claimed) is
really at, a consensus that seems to me to be necessary to
determine whether it should be chartered as a WG if  there are
going to be any restrictions at all on what that WG can
consider.  That strikes me as sad since, beyond philosophical
debates, it seems to me to be the key issue.

Just my opinion.

    john

--On Thursday, 22 December, 2005 08:55 -0800 Michael Thomas
<[email-masked]> wrote:

>> are small enough that changes are still easy and that non
>> backwards compatible changes are already expected. 
> 
>...
 
>...

---

From: Dave Crocker <[email-masked]>
Date: Thu, 22 Dec 2005 14:09:59 -0800

>     I
> no real changes are required or desirable.  

John,

1. That is not what has been claimed or sought for DKIM.  Ever.  There 
is a world of difference between protecting existing implementations and 
seeking "no real changes".

2. This misrepresentation of things has been asserted repeatedly and has 
been correctly repeatedly.

3. At this stage, repeating this misrepresentation has taken on the 
characteristic of willful distortion.

d/
-- 

  Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Thu, 22 Dec 2005 14:53:59 -0800

On Dec 22, 2005, at 12:06 PM, Frank Ellermann wrote:

> It could also work for news if we get the FWS canonicalization right.

Agreed.  The presents of the signature should not impose limitation  
upon what content (email-address) is carried.

>> Schemes related to the email-address such as S/MIME or OpenPGP are  
>> designed to support email-address limitations.
>
> Maybe they missed the point, mail without signature.  A simple way  
> to publish that all mails claiming to be from X are spam if they  
> don't have X's signature.  [ I'm just spamcop-ping 36 phishes  
> claiming to be from my bank, hilarious ]

If the MTA or MUA cached assurances (binding) found in messages  
indicating this message should always be signed, then the only  
additional lookup needed would be to confirm continuation of the  
assurance when such message is found lacking the signature.  The  
caching require to mitigate most abuse could be simply a list of  
domain names held within a local DNS zone.  Once recognition at the  
MUA becomes widely deployed, caching at the MTA would be redundant  
and not needed.

For SSP, there is a policy search walking up DNS label trees for  
nearly each and every email received, and will likely lead to  
coercion to increase the number of domains publishing records.  As an  
alternative, the recognition approach allows incremental deployment.   
For many domains, a closed-policy will be disruptive and yet an open- 
policy will likely damage their reputation.  The binding approach  
does not incur the overhead, risk reputations, or require coercion to  
mitigate policy overhead.

-Doug

---

From: John C Klensin <[email-masked]>
Date: Thu, 22 Dec 2005 19:34:25 -0500

--On Thursday, 22 December, 2005 14:09 -0800 Dave Crocker
<[email-masked]> wrote:

>>     I
>> think it has also been claimed that it is sufficiently
>> finished and mature that IETF ratification and endorsement is
>> needed, but no real changes are required or desirable.  
> 
> John,
> 
> 1. That is not what has been claimed or sought for DKIM.
> Ever.  There is a world of difference between protecting
> existing implementations and seeking "no real changes".

Dave, I'm sorry, but some of the assertions that have been made
about what "protecting existing implementations" means have been
indistinguishable to me from "no real changes permitted".  It
would also be possible to interpret those same statements as "of
course changes are permitted, but some largely undefined design
group, or group of core participants, will decide what is
acceptable and what unacceptably violates the existing
implementations, without regard to WG participant or IETF
consensus".  

My impression is that it is exactly that set of assertions, and
the associated implication that some process outside the normal
give and take of WG interactions will be used to determine which
changes are acceptable and which ones are not, are exactly what
has drawn those of us who have no DKIM-specific reservations
into this discussion.  

If that interpretation was not what was intended, I would have
expected Tony Hanson's suggestion about reuse of the XMPP
language to be welcomed, not because of pressure from on high,
but because it appeared to be an entirely sensible statement of
what was intended, a statement that was less subject to
misinterpretation than the one in the draft charter.

But you took exception to that change in language.  You
apparently saw it as coming in response to an unreasonable,
top-down, demand from a few IESG and IAB members.  I saw it as a
helpful and constructive suggestion, coming from a respected
member of the community, to get things unstuck in a way for
which we already had established precedent.  You apparently see
all of the objections and reservations that have arisen to the
language of the proposed charter as coming from people who
raised the issues during the earlier, BOF and other pre-charter,
discussions, lost, and are now trying to raise them again.
Without debating whether this is, in fact, an appropriate point
to raise those issues even if they have been raised before
(although I think that "final charter review" is exactly the
right time to raise questions of WG scope and ground rules), I
see people participating in this discussion, precisely because
of the language about existing implementations, who have not
previously been substantively involved with DKIM and who,
instead, represent some small groundswell of community
resistance to a WG that is thus constrained without any clear
understanding of who gets to interpret the rules.

> 2. This misrepresentation of things has been asserted
> repeatedly and has been correctly repeatedly.

>From my perspective, the "corrections" have been unpersuasive,
for the reasons outlined above.  They got particularly
unpersuasive when resistance appeared to Tony's suggestion of
more moderate language.

> 3. At this stage, repeating this misrepresentation has taken
> on the characteristic of willful distortion.

And those who are on the other side of what I continue to
believe is a series of misunderstandings about a reasonable and
responsible desire to clarify the text and intent could equally
well claim that a desire to stay with the current text no matter
what, and to denounce anyone who wants to try to adjust it, is
evidence that the particular text is, in fact, the result of
nefarious intent.  They, however, and to their credit, have made
no such claim.

     john

---

From: Michael Thomas <[email-masked]>
Date: Thu, 22 Dec 2005 17:18:51 -0800

> debates, it seems to me to be the key issue.

I obviously think it's closer to #4 than anything else. Note
I wasn't weighing in about whether this piece of word-smithy
vs that was better or not, just my concern that the lack of
negotiation/feedback make the backward compatibility problem
far more nettlesome than other protocols that have that
luxury. There is a substantial risk that a bunch of gratuitous
thrashing around -- or worse a greenfield makeover ala MEGACO --
will cause this effort to crater. Given MARID, I don't think
we get many chances and that this is really a situation where
the best is the enemy of the good.

As such, I think it's reasonable for the charter to limit the
scope of changes to those that will really tighten up the mature
parts of the specs instead of a, IMO, futile -- and destructive --
trip back to first principles. False dichotomy? Maybe, but not
out of the question if there is no limit at all, and that's
pretty bothersome for those of us who advocated taking this
to ietf and tried really hard to make this look like
something that would pass ietf muster.

Finally, I understand that for many people there are larger
principles at stake about the nature of ietf, etc, etc. I can't
tell you how thrilled I am that we are the posterboy for _that_
argument.

		Mike

---

From: Andrew Newton <[email-masked]>
Date: Thu, 22 Dec 2005 22:31:59 -0500

On Dec 22, 2005, at 7:59 PM, J.D. Falk wrote:

> DKIM won't be deployed widely enough to be useful to senders until  
> about a year after the IETF finishes with it.

That's a pretty interesting statement considering this argument is  
about backwards compatibility with the "wide deployment" of a  
specification that has been public for less than 6 months (draft- 
allman-dkim-base-00 has a publication date of July 9, 2005).

If anybody has an issue with the text Tony has suggested, it should  
be discussed.  Otherwise, I think this thread has reached the end its  
useful life.

-andy

---

From: Mark Delany <[email-masked]>
Date: Fri, 23 Dec 2005 04:24:23 +0000

On Thu, Dec 22, 2005 at 06:35:47AM -0800, william(at)elan.net allegedly wrote:

> pressure on DNS infrastructure

Unproved speculation. As you know, email, compared to HTTP and P2P
(neither of which sought approval from the IETF) constitutes an
increasingly tiny part of the Internet load these days. The serious
pressure comes from applications that never came near the IETF.

> when data served & answer would either come close to or exceed 512bytes 

Unproved speculation. As you know, 512 is not a UDP limit it's a DNS
implementation limit which was long ago removed by EDNS0 - an IETF
standard.

The other minor matter is that the Internet is already participating
in a billion+ DK signed and verified emails per day - I've been
watching, but as yet, no news at 11. At what point do you expect the
pressure to be noticed?

William. I admire your interest in optimizing DNS load, but, as Knuth
might ask, is it premature? If you think not, convince us otherwise.

Mark.

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 22 Dec 2005 21:11:39 -0800 (PST)

> pressure comes from applications that never came near the IETF.

That is not a proper comparison. DNS is a key protocol (not to be
confused with protocol "for keys" :) for almost all other L7 protocols
on the net. HTTP was just "another" protocol and its use would not have 
had much effect on say telnet or ftp (ok, for ftp it might as it began
to be used as replacement, but that is different matter). We have to be
a lot more careful what we choose to do with dns and I think it should
stay primarily as a protocol for "linking" domain names. to specific
data locations rather then becoming all-purpose database.

Another issue is that dns is not just client->server protocol where
impact of using it would only be limited to server that chose to
deploy dkim records and client that chose to check it.

My view is that there is enough uncertainty and that if load on [core]
protocol like dns can be minimized and moved into specific L7 protocol
like SMTP, that it should be done. And we do have easy enough way to
do it with DK-like system by using fingerprints.

> implementation limit which was long ago removed by EDNS0 - an IETF

Nevertheless for immediate future [at least 5 more years, probably 10]
512bytes is basically limit that dns records should fit in.

BTW - that case of adding EDNS extension to widely deployed system and
how slow long it takes to do is an example why adding additional key
authorization methods to DKIM would not be easy and why we should worry
about this issue right now.

> watching, but as yet, no news at 11. At what point do you expect the

The number of emails being signed and checked is actually the main
factor - especially for sites that constantly communicate with each 
other.

What would make a difference is large number of "small" domains that only
occasionally send emails but would have a signature on them requiring
checking dns and caching the public key (I predict that specialized 
optimized caching servers would be needed - in fact its somewhat in my 
area so I may even make good money if we all have this requirement ...) 
Also small mail servers that have to check all signed emails would see
these issues in even greater degree. What would also make a difference
is when users at the largest domains begin to demand to be able to use 
their own unique keys.

> might ask, is it premature? If you think not, convince us otherwise.

Nothing is premature when it comes to dns. Once you make mistake its
difficult to fix (without impacting ongoing deployment) even if other
services are known to be impacted. As I said, it comes down to that we
do have other choices to putting large records in dns and they are 
basically close to being equivalent to public keys in dns, so we should
choose those. At the very least make them available as core supported 
authorization methods so in the future if problems are found, there would 
be a backup plan that does not require upgrade of every site software.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Thu, 22 Dec 2005 21:19:03 -0800

John,

> indistinguishable to me from "no real changes permitted".  It

Please provide quotes, and please reconcile your assessment with the 
list of "real changes" already made or agreed to.

> has drawn those of us who have no DKIM-specific reservations

Wow.

I have no idea what you are talking about or what you are basing it on.

> language to be welcomed, not because of pressure from on high,

Apparently you expect the extensive, open group consensus process that 
was pursued TWICE on this matter to have no import, but the last-minute, 
vague whim of a few posters instead should hold sway.

Gosh, yes.  You are right.  It is entirely unreasonable to object to the 
change here.

>   I saw it as a
> which we already had established precedent. 

Helpfulness requires that a problem exist.  It didn't.

When the purported helpfulness is in response to an artificial problem 
created by the purported helper, things look a lot more like Munchausen 
by Proxy.

>  You apparently see

You must be basing that assessment on some bit of conjuring that has 
nothing to do with what I have actually said, since you are quite simply 
wrong.

>  precisely because

Groundswell?  Again, wow.

John, have you bothered to count just how few people are unhappy with 
the existing language?  And please distinguish "unhappy" from "willing 
to go along with a change in order to get the charter approved".  Have 
you bothered to compare your purported groundswell with the number of 
participants who contributed to developing the existing text?

And, yes, it is worth noting that two of the active objectors are IETF 
management folks, conducting a sour-grapes campaign, since they failed 
to gain support during the open charter development discussions.  Their 
efforts are all the more intriguing given that neither of them has ever 
cited a specific working group task that is likely to be needed but 
would be prevented.

d/

-- 

  Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Fri, 23 Dec 2005 01:53:27 -0500

Dave,

Unless you can cite an IETF BCP RFC that authorizes unchartered, 
self-appointed, ad hoc groups to dictate the terms of their charters, 
constrain the behavior of chartered IETF working groups, or overrule the 
decisions of IESG in chartering a group, please rest your case.

Keith