I support the new charter and thank those who spent the time
discussing it and walking through alternatives.
--Sam
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
agreed.
Tony Hansen
[EMAIL PROTECTED]
John Levine wrote:
Here is the revised proposed charter text:
Thanks for pulling this together.
If I had unlimited time to waste, I might niggle about a word or two,
but it's fine as is, and I look forward to moving ahead and getting
Here is the revised proposed charter text:
Thanks for pulling this together.
If I had unlimited time to waste, I might niggle about a word or two,
but it's fine as is, and I look forward to moving ahead and getting
some work done.
Complete ageement here. This is plenty good enough to move
I have been listening to this discussion. As the area advisor for
this proposed working group, I have made a few changes to the
paragraph that has caused so much debate. The revised text is
largely based on the XMPP charter text posted by Tony
Hansen. However, we know that some changes are
Here is the revised proposed charter text:
Thanks for pulling this together.
If I had unlimited time to waste, I might niggle about a word or two,
but it's fine as is, and I look forward to moving ahead and getting
some work done.
R's,
John
___
Ietf
Nathaniel Borenstein [EMAIL PROTECTED] wrote:
On Dec 24, 2005, at 4:09 PM, Douglas Otis wrote:
Reputation remains the only solution able to abate the bulk of abuse.
... I think most of us pretty much agree about the critical role of
reputation.
I've noticed a lot of what I call lip
On Dec 24, 2005, at 4:09 PM, Douglas Otis wrote:
On Fri, 2005-12-23 at 17:27 -0500, Nathaniel Borenstein wrote:
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
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
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
On Fri, 2005-12-23 at 17:27 -0500, Nathaniel Borenstein wrote:
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.
There is danger viewing any
On Fri, 23 Dec 2005, Stephen Farrell wrote:
Hi Eric,
Eric Rescorla wrote:
The not-DKIM proponents want something better, for some value of
better.
More accurately, we want the charter not to foreclose the option
of doing something better, on the grounds that it's incompatible.
I hope
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
Title: RE: WG Review: Domain Keys Identified Mail (dkim)
I have for some time become aware that the problem of deploying a protocol is considerably more challenging and difficult than the problem of developing a protocol.
That is the reason that only two protocols were submitted as input
Title: RE: WG Review: Domain Keys Identified Mail (dkim)
Perhaps we could provide a material proof of what John is asking for if we published the other two schemes that are essentially identical to DKIM. I can certainly try to get the VeriSign spec released.
I think that if four independent
Nathaniel Borenstein [EMAIL PROTECTED] wrote:
On Dec 21, 2005, at 12:23 PM, william(at)elan.net wrote:
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
Branching off from the interminable justifiable changes thread
--On onsdag, desember 21, 2005 23:54:56 -0800 Cullen Jennings
[EMAIL PROTECTED] wrote:
Related to how much the charter pre-supposes the solution, the sentence
that Public keys needed to validate the signatures will be stored
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
Keith,
Keith Moore wrote:
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
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
If there were an I-D describing such a protocol, I'd be interested in
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
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,
Said individuals have also been known to make
misleading statements to support their arguments.
I'm thinking we must be coming to the end of productive discussion...
Spencer
___
Ietf mailing list
Ietf@ietf.org
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
On Thu, 22 Dec 2005, Barry Leiba wrote:
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
Keith Moore wrote:
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
Cullen Jennings wrote:
My current understanding is that the deployments
are small enough that changes are still easy and that non backwards
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
Michael,
Nice note.
One point, however:
Michael Thomas wrote:
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
We have agreed to the addition of an enhancement that
Dave Crocker wrote:
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
On Dec 22, 2005, at 8:38 AM, Keith Moore wrote:
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.
My concern regarding the charter is related
'nowsp' canonicalization does not exist in DKIMv2 (-base-01). It was
eliminated, rather than deprecated, because it created a vulnerability.
sorry. i had misunderstood that line of discussion. and, yes,
vulnerability counts as a showstopper.
While some -base-01 verifiers may
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
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
--On Thursday, 22 December, 2005 14:09 -0800 Dave Crocker
[EMAIL PROTECTED] 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
John C Klensin wrote:
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
On Thu, Dec 22, 2005 at 06:35:47AM -0800, william(at)elan.net allegedly wrote:
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
On Fri, 23 Dec 2005, Mark Delany wrote:
On Thu, Dec 22, 2005 at 06:35:47AM -0800, william(at)elan.net allegedly wrote:
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
John,
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
Please provide quotes, and please reconcile your assessment with the
list of real changes already
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.
Dave,
Unless you can cite an IETF BCP RFC that authorizes unchartered,
self-appointed, ad hoc
Ted,
Ted Hardie wrote:
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
Hi Eric,
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
--On Tuesday, 20 December, 2005 18:50 -0800 Dave Crocker
[EMAIL PROTECTED] wrote:
Having this point in this charter mostly serves as a
statement of mistrust, rather than providing any useful
education or constraint.
...
Adding such a statement is all about education. It is
perfectly
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,
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
On Wed, 21 Dec 2005, John C Klensin wrote:
(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
There is no wide deployment of DKIM. What is there are several
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
John,
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
--On onsdag, desember 21, 2005 05:36:08 -0800 william(at)elan.net
[EMAIL PROTECTED] wrote:
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
On Wed, 21 Dec 2005, Harald Tveit Alvestrand wrote:
--On onsdag, desember 21, 2005 05:36:08 -0800 william(at)elan.net
[EMAIL PROTECTED] wrote:
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
At 9:07 AM -0500 12/21/05, Tony Hansen wrote:
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
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
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
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.
That is almost never an appropriate goal for an IETF working group
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.
Dave,
You keep making statements like that without a shred of
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
It's also a principle of good engineering that you don't make unnecessary
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
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
Ted Hardie wrote:
At 9:07 AM -0500 12/21/05, Tony Hansen wrote:
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
Ted Hardie wrote:
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
Fellow DKIMers,
Barry Leiba wrote:
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.
Well, I guess no one else is concerned about the sequence that has just
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
Dave Crocker wrote:
and now the chairs quickly concede the change, even before getting
support from the rest of the group.
'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
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
___
Ietf mailing list
Barry,
I understand the principle you're fighting for, Dave. And I think it
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
Brandenburg InternetWorking
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
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
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
At 2:44 PM -0800 12/20/05, Dave Crocker wrote:
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.
Ted,
We could choose to have every charter repeat every premise for all IETF work.
That would be wasteful, at best.
It's also a principle of good engineering that you don't make unnecessary
changes to deployed code.
But since only *some* IETF working groups begin with work that involves
At 3:49 PM -0800 12/20/05, Dave Crocker wrote:
1. As interesting as such a discussion might be, it has no effect on the
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
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
Ted.
It has an effect on the technical work of the IETF, by creating a new mechanism
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
At 2:44 PM -0800 12/20/05, Dave Crocker wrote:
The charter
needs to reaffirm that the IETF has change control over the
Having this point in this charter mostly serves as a statement of
mistrust, rather than providing any useful education or constraint.
Fully disagree. There is plenty of
Having this point in this charter mostly serves as a statement of
mistrust, rather than providing any useful education or constraint.
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
Dave == Dave Crocker [EMAIL PROTECTED] 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
Dave Crocker [EMAIL PROTECTED] wrote:
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
Sam,
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
The IESG wrote (quoting the proposed DKIM charter):
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
77 matches
Mail list logo
