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

Re: Comments on draft-ietf-ipsec-ike-01.txt (long)

On Thu, 10 Jun 1999 16:31:09 PDT you wrote
> Dan Harkins wrote:
> > So we can mandate the support for negotiating up things like key lengths bu
>t
> > not require that it be done every single time. If someone wants to have a
> > policy that says, "128 bits no more no less" then they are free to do that
> > without violating any IETF requirements just as Ran (and you, and me) is fr
>ee
> > to type telnet 1.2.3.4 and not violate any IETF requirements.
> > 
> >   As I stated before, the text that is causing so many people problems is b
>eing
> > rewritten and the word "policy" will not show up anywhere. No one is advoca
>ting
> > overriding any policy. But the text said SHOULD. Some want MUST. So, keepin
>g
> > in mind the difference between mandating implementation support versus
> > mandating use, what should it be? SHOULD or MUST? Is there a reason not to
> > support this capability (again, keeping in mind the difference between
> > mandating implementation support versus mandating use)?
> > 
> >   Dan.
> 
> Maybe part of the problem in this debate is related to another word that
> keeps cropping up, i.e. "mandate".  I have a Webster in hand that lists
> the first definition for mandate as "1. an authoritative order or
> command, especially a written one". This has been part of what I viewed
> as problematic with this argument all along.

Look, we "mandate" support for manually keyed IPSec SAs. That doesn't mean
that every single IPSec SA must've been manually created. Implementations
are free to use key exchange protocols to dynamically establish SAs. Can't
you see the difference between mandating support and mandating use? 

> In most cases, the appropriate behavior is specified by the policy we
> already support, and is permitted via the use of multiple proposals,
> e.g. (dh-1 OR dh-2 OR dh-5). The problem seems to be only with certain
> algorithms which permit variable key lengths (blowfish keeps coming up),
> and I have come around to agreeing that this case is not so
> cut-and-dried. Some have suggested a policy capability for specifying
> "accept keylength >= x", and this seems sensible, since the alternative
> is exhaustive enumeration in the proposals, which *I* sure don't want to
> parse. I think the point here is that we need a way to specify ranges
> somehow, i.e. up to x, x only, a <= x <= b, etc. 
>
> I guess my bottom line is showing again: the admin needs to be able to
> control the behavior such that discovery of a weakness only requires
> reconfiguration, not an IKE patch, and such that if they want to limit
> strength for whatever reason, they can. It seems to me that this could
> be accomplished if there were key length attributes of some sort which
> allowed us to express such key length ranges in our proposals. Then, we
> could require as part of the spec that implementations support these
> attributes, subject of course to local policy.

I guess I don't see how your bottom line is effected then since we're
not talking about mandating use. "require...that implementations support
these attributes subject...to local policy"? We're not talking about
imposing a mandate on end users or on their policy, we're talking about
imposing a mandate on implementors. 

This idea of a cipher becoming "weak" with longer keys is bizarre. Any
cipher which supports a variable-length key that becomes weaker as the
key becomes longer is a cipher with a fundamental problem and it should
not be used period. There are always ridiculous, hypothetical, and 
unrealistic edge conditions (and a fictitious and fatally flawed cipher 
which some admin insists on using is a prime example) but focusing on
them only confounds the issue. The issue at hand is whether to impose
a requirement on implementations to support negotiating up certain
attributes. It is not (and let me say again, IT IS NOT!) whether end
users must configure their boxes to do so. 

  Dan.
Follow-Ups: References: