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

Re: IPSEC WORKING GROUP LAST CALL



It's a bit late in the game for this kind of criticism. However,
some of your comments are so basically wrong, that I'll take the
time to correct some of your misapprehensions.

Alex Alten <Andrade@ix.netcom.com> writes:

> IPSEC WG,
> 
> These are my main technical criticisms of the current set of IPSEC 
> documents.
> 
> 1. No data recovery of an encrypted IP datagram payload.
> 
>    Regardless of the merits of the design by not supporting this 
>    requirement it will probably kill IPSEC as a viable Internet 
>    standard.
I'm not sure what this is supposed to mean.

> 2. Interoperability requirement not met.
> 
>    To ensure interoperability only one cryptographic mechanism should 
>    specified, and no others should be allowed.  The current proposal
>    allows an unlimited variety to be used, it seems primarily to allow 
>    the standard to scale cryptographic strength upwards.
I disagree with the position that only one cryptographic
algorithm should be available. Different systems have different
security requirements. However, that said, the specs do specify
required algorithms, precisely to facilitate interoperability.

>  The requirement 
>    for DES-CBC to be always implemented cannot be met because objection
>    #1 cannot be met with it.  Probably RC4 with 40b keys will become 
>    the de facto interoperable mechanism (this has happened to SSL).
You're really going to need to explain what objection (1) means here,
since I don't see what (good) properties RC4-40 has that DES-CBC
doesn't. It almost seems like when you say Data Recovery, what you
want is an encryption algorithm that doesn't provide confidentiality
against a dedicated attacker.

> 3. IPSEC does not properly fit with the IP routing model.
> 
>    It force fits the concept of a security session (SA) onto the IP 
>    datagram routing model.  Certainy the concept of a user id does 
>    not fit the IP address model.
Yep. This is a problem. Unfortunately, endpoint naming is always a problem.

>  The requirement that AH must know 
>    about the IP header structure breaks the general rule of protocol 
>    layering.
I agree, this is bad. Unfortunately, it's also necessary if you
want to have the features that AH provides, namely only one set of
headers for the datagram. This has some advantages, including a slightly
smaller packet size. 

> 4. The design is too complex
> 
>    This design seems to have been driven primarily by the following.
> 
>    A. The desire to side-step export restrictions if necessary.
> 
>       This has caused two protocols, AH & ESP, to be specified.
>       If #1 is properly satisfied then AH can be eliminated.
This misunderstands the history of IPSEC. AH and ESP exist because
they provide subtly different security services. 

>    B. The desire to use a proven cipher, i.e. DES.
> 
>       This decision has had a profound impact on the design.  Because
>       DES is slow, it has forced encryption & decryption to the edge
>       hosts,
This is incredibly confused. The reason for having cryptographic
processing is to provide end-to-end security without trusting
the routers in between. For the motivation behind this, I suggest
you read "Security Mechanisms in High Level Network Protocols"
by Voydock and Kent, and "End To End Arguments in Systems Design"
by Clark et. al.

>	There
>       are many excellent high performance ciphers available many of them do 
>       not require IV's or pad bytes.  Many of these can be proved to be very 
>       secure, often in a manner obvious to most competent engineers.
This is simply false. There are in fact no cipher systems which can be
proven to be secure (with the exception of the One Time Pad). That said,
there are very few publicly available ciphers with any substantial
body of analysis behind them, and all of them are block ciphers. Of
these ciphers, DES has by far the most analysis. Moreover, IVs and
pad bytes simply don't add that much complexity to the implementation.

>    C. The desire to use a public key algorithm.
> 
>       This decision has also had an impact on the design.  Because PK is 
>       so slow this has also contributed to the use of the SA construct
>       instead of other methods which could more closely match how
>       IP routing really works.  It makes the management of trust more
>       difficult, for example deleting untrustworthy hosts in a timely 
>       manner.
Do you have another suggestion besides using Public Key?

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."


References: