[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt]



| From: Dan Harkins <dharkins@cips.nokia.com>

|   We?

There are two authors on the comments to which you were replying.  If
you read to the bottom, you'd have noticed.

| Are you a doctor?

Yes.  So what?

|   You can infer any meaning you want and have it impact your implementation
| but then don't say that if I don't agree with your implementation that
| I am somehow non-compliant:
| 
| On Wed, 12 Jul 2000 19:09:17 "D. Hugh Redelmeier" <hugh@mimosa.com> wrote:
| 
|  "We infer from some comments that some implementations do not enforce the
|   requirement that Message IDs be unique.  Although this isn't RFC
|   compliant, the suggestion is that the RFCs be changed!"
| 
| Your (plural) inference is correct but that does not mean that I'm not
| RFC compliant!

We read the word "unique" as having its standard meaning and hence
reach the stated conclusion.  You seem to read it as having some other
unspecified meaning ("kind of rare"?) and hence essentially
meaningless.  If you can read any word that vaguely, there is no
standard.

| What is the security hole? How can a replayed Quick Mode packet induce
| either party to accept forged packets?

Please read what we wrote; at no time did we claim that a security hole
resulted.  Interoperability problems are less serious than security holes,
but are far from negligible -- people will not use a security system that
doesn't work.

Subsequent discussion on the list has made some of these issues
clearer.  It does look as if enforcing Message ID uniqueness could
reduce the cost to the victim of a replay-QM1 DOS attack.

Your other postings have been constructive.

Thanks,

Hugh Redelmeier
hugh@mimosa.com  voice: +1 416 482-8253





























On Thu, 13 Jul 2000, Dan Harkins wrote:

| Date: Thu, 13 Jul 2000 18:25:23 -0700
| From: Dan Harkins <dharkins@cips.nokia.com>
| To: Henry Spencer <henry@spsystems.net>
| Cc: D. Hugh Redelmeier <hugh@mimosa.com>,
|      IPsec List <ipsec@lists.tislabs.com>, Hugh Daniel <hugh@toad.com>,
|      John Gilmore <gnu@toad.com>
| Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] 
| 
|   We? Are you a doctor?
| 
|   You can infer any meaning you want and have it impact your implementation
| but then don't say that if I don't agree with your implementation that
| I am somehow non-compliant:
| 
| On Wed, 12 Jul 2000 19:09:17 "D. Hugh Redelmeier" <hugh@mimosa.com> wrote:
| 
|  "We infer from some comments that some implementations do not enforce the
|   requirement that Message IDs be unique.  Although this isn't RFC
|   compliant, the suggestion is that the RFCs be changed!"
| 
| Your (plural) inference is correct but that does not mean that I'm not
| RFC compliant!
| 
| What is the security hole? How can a replayed Quick Mode packet induce
| either party to accept forged packets?
| 
|   Dan.
| 
| On Thu, 13 Jul 2000 17:33:33 EDT you wrote
| > On Wed, 12 Jul 2000, Dan Harkins wrote:
| > >   For all the complaints about poor definition of terms (e.g. "system")
| > > it seems surprising that a private definition of "unique" would guide
| > > an objection to advancement of this draft.
| > 
| > "Unique" is a word readily found in dictionaries; our definition is the
| > standard one.  Although there is a vague implication in the RFC that the
| > uniqueness is intended to be only within the space of simultaneous
| > negotiations, neither this nor any other restriction on the scope of
| > uniqueness is actually stated.  We do not feel it is unreasonable to
| > interpret this as meaning that message IDs are supposed to be *unique*,
| > in the strict dictionary sense of the word (within the obvious sanity
| > constraint that different hosts cannot plausibly be prevented from
| > choosing the same message ID).
| > 
| >                                                           Henry Spencer
| >                                                        henry@spsystems.net
| > 
| 




Follow-Ups: References: