[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SKIP Design & Applicability Statement
>If the key-compromise is undiscovered, nothing prevents the
>attacker from using this second source of plaintext, and
>this is the case I was pointing out as the distinction
>between discovered and non-discovered key compromise.
Points well taken. Of course, having to use a stolen key to log into a
machine to retrieve plaintext carries a far greater risk of detection
than using a stolen key to decrypt some surreptitiously intercepted
ciphertext. I'm sure that NSA, for example, is far more likely to do
the latter than the former. :-)
Phil
To: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>, ipsec@TIS.COM
To: jis@mit.edu, gnu@toad.com
To: iesg@ietf.org
Subject: IPSEC WG chairs unresponsive, disruptive, and biased
In-Reply-To: <199609162035.NAA06638@mailsun2.us.oracle.com>
Date: Wed, 18 Sep 1996 17:01:10 -0700
From: John Gilmore <gnu@toad.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9609190719.aa05577@neptune.TIS.COM>
I too submitted revisions to the draft Montreal minutes, to provide a
web pointer for my "rapid IPSEC deployment" proposal, and to record
what specific questions were asked by Jeff Schiller at the end of the
"key managment" meeting, and what the rough votes in response were.
None of these revisions were reflected in the minutes posted this week
by the co-chairs.
I have heard complaints from a wide variety of people about the
conduct of the IP Security working group co-chairs. A certain amount
of it I could attribute to general grousing. But I continue to see
examples of how the co-chairs act to disrupt and skew, rather than to
foster, the process of reaching rough consensus. I will refrain from
speculation on whether this is intentional on their part, or whether
they are merely not suited to the task of managing a complex and
contentious working group.
I would welcome input from the Working Group and from IESG members on
how to handle this situation. I think it has been swept under the rug
for far too long.
IESG readers may not have seen Ashar Asiz's recent messages regarding
how the coverage of his SKIP proposal in the minutes has been highly
biased for the last two working group meetings. I'll be glad to
forward them to interested parties, or they can be found in this
week's ipsec@tis.com mailing list archives. Here is an excerpt:
> Also, when there are competing proposals, I believe some
> consideration should be given to fairness in the way the various
> proposals are described. I refer specifically to the use of
> adjectives such as "significant overhead", "hard to implement
> and scale" and "claimed" support of multicast when describing
> SKIP. By contrast, adjectives used for ISAKMP/Oakley are
> "very general", "very flexible", etc.
In my particular case, the minutes report that Jeff's straw polls
"showed significant differences of opinion between Oakley/ISAKMP and
SKIP", when in fact, as Jeff had told me in advance, he had
deliberately structured his questions to avoid doing straw-polls on
particular algorithms. Here's the minutes coverage, followed by my
unaccepted revisions to the minutes. Jeff should have notes that
confirm which description is more complete and more accurate.
> Closing discussions were process oriented, i.e., how will the WG decide
> what will become the default key management standard for IPSEC ? Jeff
> Schiller conducted straw polls which showed significant differences of
> opinion between Oakley/ISAKMP and SKIP, although everyone wants a quick
> resolution to the issue! Jeff suggests having a special committee come back
> with a justifiable resolution.
Message-Id: <199608060655.XAA10933@toad.com>
To: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
cc: ipsec@TIS.COM, gnu
Subject: Re: IPsec Minutes from Montreal
In-reply-to: <199608052345.QAA16081@mailsun2.us.oracle.com>
Date: Mon, 05 Aug 1996 23:55:26 -0700
From: John Gilmore <gnu@toad.com>
Some minutes additions from my own notes:
Details on my presentation on rapid deployment of IPSEC in the first
meeting are available at http://www.cygnus.com/~gnu/swan.html.
Jeff Schiller's closing discussions in the second meeting included
these "straw poll" questions, with my rough estimations of the
audience reaction. He said he deliberately structured the questions
to avoid a straw-poll on particular algorithms, but instead focused on
our goals or process.
Should we let the marketplace decide on a key managment standard,
or should we pick one and move forward?
Marketplace - 2/5
Pick one - 3/5
Should we favor generality, or simplicity?
Generality - 2/5
Simplicity - 3/5
Do we have to have a plan by the next IETF?
On this we have consensus -- YES.
Should Jeff grab a few of the WG people who are known not to be committed
to any proposal, and together decide?
Strong consensus that this was not the way to go.
This was when he suggested convening a small group, largely composed of
the authors/proponents of existing proposals, to try to hammer out a
compromise proposal. He also said that if this group didn't come up with
anything by September, Jeff would personally choose one as the standard,
though he did not want to be forced to do that.
John
To: John Lawler <jlawler@vpnet.com>
Cc: ipsec@TIS.COM, Bill Sommerfeld <sommerfeld@apollo.hp.com>, gnu@toad.com
Subject: The WG's inability to choose is good in this case.
In-Reply-To: <2.2.32.19960917233303.00685998@best.com>
Date: Wed, 18 Sep 1996 18:21:43 -0700
From: John Gilmore <gnu@toad.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9609190719.aa05593@neptune.TIS.COM>
> My point is that if we are still at this stage of the game at this late
> date, then something is seriously wrong with the process.
Someone else suggested something similar to me: that the WG was
seriously stuck and that nobody had the guts to fix it. My insight
was that the WG is having a largely correct response to the set of
technical proposals placed in front of it.
We, the working group, are showing good sense, actually. It's not a
guts issue. If we had a credible alternative we'd head toward it like
lemmings. The problem is that none of the alternatives is credible.
Each has strengths and weaknesses; each has problems; none solves the
entire problem we're trying to solve.
We are stuck for a good reason; we don't want to make a good political
decision. We want to make a good technical decision, and there is no
good technical choice for securing the Internet right now. The IPSEC
process is working. It looks too slow because the technical proposals
and implementations need to evolve faster than they have been, not
because the consensus process has failed.
John
References: