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

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

  I really miss Ran Atkinson. During a discussion on mandating support 
for secure DNS he said the following:

  "Hmm.  Perhaps permit me to narrow those statements a bit to try to clarify
   something (mandating implementation support vs. mandating use) that
   periodically causes confusion within the IPsec WG.

   "The IETF requires that _implementations_ of IP also _implement_ support for
   DNS.  The IETF does NOT require that users actually _USE_ DNS.  Now most 
   users DO use DNS because it is widely implemented and it is often easier to
   use than typing an IP number.  However, on occasion users (e.g. me) don't 
   use DNS and instead just type an IP number on the command line (e.g. 
   "telnet 1.2.3.4") and this isn't violating any IETF requirement."

So we can mandate the support for negotiating up things like key lengths but
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 free 
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 being
rewritten and the word "policy" will not show up anywhere. No one is advocating
overriding any policy. But the text said SHOULD. Some want MUST. So, keeping
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.

On Thu, 03 Jun 1999 14:22:45 PDT you wrote
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > From: Derrell D. Piper [mailto:ddp@network-alchemy.com]
> > Sent: Thursday, June 03, 1999 12:39 PM
> > 
> > >   So let me ask the entire working group: should vendors
> > >   be prohibited from accepting a key length greater than 
> > >   what they have configured? Should they be prohibited from 
> > >   accepting a stronger group? 
> > 
> > Absolutely not and I'd go so far as to make it a SHOULD 
> > instead of a MAY.
> > 
> > We're trying to design good security, not workarounds for bad 
> > implementations.
> >
> Hmmm, this means if a policy _explicitly_ states 128 bit encryption
> (note, the policy _did not_ state 128 bit encryption or greater),
> then IKE has the right to change the policy to be 128 bit or greater?
>
> IMHO, IKE must act dumb when it comes to policy and must not assume
> it knows better then whatever set that policy. Here we seem to be
> arguing that good security is allowing stronger encryption even when
> stronger encryption is precluded by the policy. I would argue that
> good security offers no such surprises.
> 
> I can imagine applications that may not want to manage, or be capable
> of managing, the extra 320 bits (above 128) possible in in Blowfish.
> I can imagine machines not wishing to do the extra work required of a
> stronger group.
> 
> 
> 
> - -Michael Heyman
Follow-Ups: References: