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

Re: IPSEC WORKING GROUP LAST CALL

>>>1. No data recovery of an encrypted IP datagram payload.
>>This is a feature, not a bug, by strong consensus...
>
>I understand this.  I am certain that this requirement will not change for 
>the forseeable future, regardless of our consensus.  I am also certain that 
>this requirement can be met, in a manner that would satisfy our community...

A significant fraction of the community will not be satisfied by any
protocol which incorporates key recovery.  The objection is not to the
technical details of key recovery, but to its presence in any form.

Key recovery is readily added by separate mechanisms, e.g. a separate 
key-escrow system, but is not readily removed if it is present in the 
central protocol.

>>>   C. The desire to use a public key algorithm.
>>Use of a public key algorithm is an engineering necessity, not a desire.
>
>Here I think we differ on what the secure IP network model should be.  
>I believe that it should be a resource owned by an organization or a 
>company that wants to control access to it and protect their 
>communications...

What of two organizations which wish to limit access to, and protect,
their inter-organization communications?  This is not an imaginary
example:  the auto industry has been pushing IPSEC, because the car
manufacturers want secure electronic communication with their part
suppliers.  Note that the pattern of trust and non-trust here is complex,
and probably could not be satisfied by a single key authority or a small
number of them:  many of the companies involved are competitors, and the
supplier relationship is a complex dynamic directed graph, not a simple
fixed tree.  Any attempt to solve this with private keys ends up inventing
something vaguely analogous to a public-key system, but more complex and 
with more vulnerabilities. 

IPSEC, like IP, is not just for single-organization private networks.
A *general-purpose* cryptographic security system must use public-key
technology. 

                                                      Henry Spencer
                                              henry%spenford@zoo.toronto.edu
Follow-Ups: