newest Draft Charter:
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.
versus
Stephen:
I don't believe there is a
requirement for the d
Is it ok with folks to be required to replace essentially all of the
current software, administration and user deployment?
No, UNLESS it's _really_ the Right Thing. I'm convinced that the new
charter language presents a sufficient check on capricious change.
However Stephen's comment creates
- Original Message -
From: "Dave Crocker" <[EMAIL PROTECTED]>
To: "IETF DKIM pre-WG"
> Is it ok with folks to be required to replace essentially all of the
> current software, administration and user deployment?
I'm not convinced there is sufficient installed base that should preempt
ma
Dave,
Dave Crocker wrote:
newest Draft Charter:
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.
versus
Stephen:
I don't believe
Stephen,
(Folks -- This sort of exchange is exactly why I decided to burden the
list with my concern. I believe that it is important that we get as
much group alignment (consensus) about the "strategic" goals and
requirements for this standardization process as possible, as early as
possible
On October 17, 2005 at 09:07, Dave Crocker wrote:
> 2. Incompatibility comes in a variety of forms. I think that for our
> purposes, the most significant different is between a change that
> permits senders to continue with their old behaviors (over the wire) and
> still have signatures work f
On Mon, Oct 17, 2005 at 06:02:18PM -0500, Earl Hood allegedly wrote:
> Hector raised a good point about attackers being able to exploit
> this. I.e. If standardized DKIM is more secure, attackers will
> exploit the legacy user base to get around the more secure version.
This is surely within th
Dave,
For me this is boiling down to whether or not the wg is allowed
to change the signature construct, or prevented by the charter
from so-doing, but read on...
Dave Crocker wrote:
Stephen,
(Folks -- This sort of exchange is exactly why I decided to burden the
list with my concern. I beli
Is it ok with folks to be required to replace essentially all of
the current software, administration and user deployment?
That's three things.
right. bigger impact. that was my point. ensuring upward
compatibility for an installed base can get messy.
Nope. I meant that you conflated
On October 18, 2005 at 05:14, Mark Delany wrote:
> If a signer feels vulnerable to exploitation, they will only use the
> safest signature mechanism available. Alternatively, if the signer is
> more interested in compatibility they might choose a deployment that
> maximizes successful verification
Oh drat!
I just posted a half-written response and did not mean to. Please just
ignore it. I want to talk with Stephen offline before burdening the
list with more of this exchange.
A thousand apollogies.
d/
Dave Crocker wrote:
Is it ok with folks to be required to replace essentially
I'm catching up, so pardon me if I didn't see a response to Dave's
question on
this too:
Stephen Farrell wrote:
t this that there'll be (though there'll always be some:-)
But, I think the charter text is fine btw.
Is it ok with folks to be required to replace essentially all of the
current
Michael,
Michael Thomas wrote:
Stephen Farrell wrote:
First, the current s/w will have to change since we're changing
the signature construct (c14n & maybe the digest thing).
>
When did we agree to this?
I thought changing the c14n actually was agreed? Changes to
the signature construc
Stephen,
The point is that changes to the signing process are always
imcompatible - the best you can do for backwards compatbility
is sign twice or else allow an option to produce a backwards
compatible signature format. But I believe we're likely to end
up with the MUST-implement being the more
Dave,
Dave Crocker wrote:
Stephen,
The point is that changes to the signing process are always
imcompatible - the best you can do for backwards compatbility
is sign twice or else allow an option to produce a backwards
compatible signature format. But I believe we're likely to end
up with the
Stephen Farrell wrote:
I thought changing the c14n actually was agreed? Changes to
the signature construct would appear to have some support on the
list. Formally of course none of these changes are agreed
since we're not yet a wg.
Sorry -- my decoder ring didn't decode c14n and I thought
it wa
I would be surprised though if the result for the signature construct
(which may be a bit of a special case here) didn't have the "best"
security option as the MUST-implement, even if it has the legacy
signature construct as a MAY-emit. But we'll see when we get there...
Just to be obsessively
Dave Crocker wrote:
I would be surprised though if the result for the signature construct
(which may be a bit of a special case here) didn't have the "best"
security option as the MUST-implement, even if it has the legacy
signature construct as a MAY-emit. But we'll see when we get there...
Michael Thomas wrote:
Stephen Farrell wrote:
I thought changing the c14n actually was agreed? Changes to
the signature construct would appear to have some support on the
list. Formally of course none of these changes are agreed
since we're not yet a wg.
Sorry -- my decoder ring didn't decod
On Oct 15, 2005, at 5:32 PM, Dave Crocker wrote:
newest Draft Charter:
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.
versus
St
I understand there is a desire not to introduce many more things or
drive the spec in new directions, and I agree with that. Having said
that, it is better to make any changes now while adoption is low than
wait until adoption is much higher.
On the other hand, doing more work takes more ti
On Oct 21, 2005, at 3:51 PM, Dave Crocker wrote:
On the other hand, doing more work takes more time. More time
means more delay getting more adoption.
If you are characterizing any change as more work, then you are
arguing for a rubber stamp.
In fact I have been getting a sense of some
On Oct 21, 2005, at 12:51 PM, Dave Crocker wrote:
I understand there is a desire not to introduce many more things
or drive the spec in new directions, and I agree with that.
Having said that, it is better to make any changes now while
adoption is low than wait until adoption is much hi
Andrew,
If you are characterizing any change as more work, then you are
arguing for a rubber stamp.
Oh? You mean that doing more work does NOT take more time?
What I am "arguing for" is careful attention to the question of
urgency. Some folks see an urgent need for this standard. Some do
Please,
This time in BoF chair mode.
Discussing things like "kludges", "infinite improvements",
"rubber stamp" etc is just not productive for either
supposed "side".
I doubt that anyone is really suggesting any of those things
so let's try keep it grounded.
There's just no point in having tha
Discussing things like "kludges", "infinite improvements",
"rubber stamp" etc is just not productive for either
supposed "side".
right.
d/
___
ietf-dkim mailing list
http://dkim.org
Stephen,
I'm sorry for contributing more heat than light to this conversation.
And to answer Dave's question: I was not calling DKIM a kludge. I
rather like the spec. I was merely attempting to state a preference
against instituting a kludge for the sake of backwards compatibility.
Again
27 matches
Mail list logo
