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

Re: notes from developer's portion of IETF meeting

Dave,

	I agree that it is always approrpiate to ask whether one is
distorting a protocol like ESP to accommodate a "special need" for some
application.  If so, then leave the common protocol alone and suggest that
the application do something application-specific.  However, this is not
the case here.  The example you cite "...MACing entire kilobytes at a
time..." is completely off base for this context.  One of the aspects of
packet voice and packet video that makes use of crypto authentication
relatively expensive is the small size of the packets.  So the "custom
optimazation" you cite is totally inapprorpiate here.

	You note that authentication should be faster than encryption,
which is often true, but I don't see why this is relevant to the argument.
If I am willing top accept the delay and the possible throughptu
limitations imposed by encryption, is that supposed to imply that I will
not mind the additional delay and the throughout limits that adding HMAC
will imply?  Unless we have parallel processing of the ESP packet (which
probably will not be common), the delay imposed by the HMAC computation is
serial and thus one ought not assume that this added delay is not a problem
just because the encryption delay may have been acceptable.

	I think we're loosing sight of the issues here.  Contrary to your
comment, we are not "carving out a hole" in the specs.  I suggested that it
is reasonable to allow negotiation of an ESP-protected SA without
authentication.  This is a characteristic of the current IPSEC RFCs and I
merely indicated a plan to preserve this modularity.  This is not a change
from the previously issued specs. We have had additional transforms that
have been published since the base RFCs, but the current RFCs don't require
combined encryption and authentiction for ESP (the default transforms don't
do this), nor do they precude definition of new transforms that have that
requirement.

	The objections to retaining this modular feature seem to be based
on several different observations:

	1.  Under some circumstances, use of encryption w/o authentication
can result in violations of confidentiality, as Steve Bellovin has pointed
out.  I agree that use of ESP with encryption (but w/o authentication)
would be inappropriate in most cases where such attacks could be mounted.
If one is electing encryption, it is inappropriate to use ESP in a fashion
that could undermine the confidentiality service that is implied. However,
one can safely use encryption w/o authentication in some contexts because
the network enviromment effectively precluded the sort of attacks that
would compromise confidentiality.  So the thrust of this argument is that
we ought to foolproof IPSEC to prevent selection ofpotentially dangerous
security service combinations.  I'll address this arguemnt below.

	2. Some forms of chosen plaintext attack are facilitated by use of
encryption w/o authentication.  This is true, but I am not at all persuaded
by the argument.  History has sihown many ways in which chosen plainetext
attack scan be launched against systems, so closing this one attack path
does not, by itself, seem worth removing a potentially useful function.

	3. Encryption w/o authentication is dangerous because all packets
should be authenticated.  This seems like another insistance on
foolproofing IPSEC, i.e., preventing selection/configuration of any
combination of options that could lead to insecurity.  I argue that one may
use higher level authentication mechanisms in conjunction with lower level
encryption to achieve a reasonable set of security features for an
application.  This may be more attractive than either turing on all of the
security services offered at a lower layer, or implementing all of the
services in the application.


I appreciate the notion that most users are not prepared to make
determinations of when selective use of encryption w/o authentication is
appropriate, and thus one can argue that we ought to change the spec to
prevent use of ESP in a fashion that might subject them to such attacks.
However, I am hesitant to take this approach.  Experience shows that we
cannot do that for all elements of a system; trying to do it in this narrow
context deprives users/system designers of flexibility.  Why don't we also
say that you cannot implement IPSEC if the crypto will be done in software,
which is susceptibale to many forms of attack that hardware crypto would
prevent?  Why not preclude implemenmtation in a typically managed Unix
workstation, since such a worksta tion is subject to many attacks that will
circumvent IPSEC, as opposed to use with a more secure Unix platform?
These and other vulnerabilities associated with use of IPSEC present
significant opportunities for attack, but we're willing to live with them.
If we decide to insist on authentication for all encrypted packets, then we
must do so without the expectation that this decision will really foolproof
use of IPSEC, and with the understanding that it will impose additional
burdens on some users.  Also, as noted in another message I just sent,
there may be crypto modes that are not subject to the sorts of attacks that
Steve Bellovin has cited, in which case precluding authenticationless ESP
is unduly restrictive for a protocol that is supposed to be algorithm
independent.

Steve
References: