[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Short keys * Options, combinations, and negotiations => simplicity
John,
I agree with some, but not all, of your comments. My goal in
working with Ran on all three of the IPsec top level documents (the
architecture, AH and ESP specs) is to unify and simplify the set of
documentation. This should improve readibility and make it easier to
document and to add new algorithms, which I believe is a generally good
thing. I also want to ensure that compliant implementations incorporate a
set of capabilities that make them generally useful (not unduly
constrained) and manageable.
I agree, though, that even if it is easy to document new algorithms
or modes or security features, that does not mean that one should
proliferate such combinations of options needlessly. The usual approach
in these sorts of situations is to define a mandatory, minimum set of
features that all implementations must include (even if they are not always
invoked), to facilitate interoperability. Then additional features may be
defined and implemented by some, but not all, vendors. There is clearly an
element of value judgement in selecting the required feature list, and we
have had that discussion in part before, but it's not really done yet.
Finally, given the move to unify the various transform definitions
in ESP and AH, we don't need a 3DES-HMAC-AR transform. We need a 3DES
description and an HMAC description (with you choice of hash functions).
The AR feature will be defined in ESP and AH as an option. I do not agree
with what I interpret as your suggestion that 3DES (vs. DES) become the
default encryption algorithm. The IAB memo on crypto policy does not
strike me as mandating such. Moreover, in selecting any safeguard, one
must balance percieved threats against costs. While you clearly precieve
NSA as a threat, I don't find that most of my commercial clients share that
view. They are more concerned about hackers, criminals, and other
adversaries for whom DES is a reasonable countermeasure. Moreover, a
balanced security design does not incorporate very strong measures in some
areas while leaving gaping holes in other areas. If we were to mandate
3DES for IPsec, this would generally be inconsistent with the environments
in which the technlogy will be used (e.g., software crypto, pseudo-RNGs,
COTS OSs like most Unix and Windows platforms, etc.). Providing a 3DES
option for those users who do percieve a threat for which this algorithm
and key size are appropriate, and for which the complementary security
safeguards are consistent, is an appropriate means of accommodating a range
of user requirements in a standard protocol.
Steve