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

Re: Comments on latest IPSP drafts


From:  Mark H Linehan/Watson/IBM Research
        <linehan@watson.ibm.com>
To:  ipsec <ipsec@ans.net>
Cc:  "Donald E. Eastlake 3rd" <dee@world.std.com>
Mime-Version:  1.0
Content-Type:  Text/Plain
}Donald Eastlake commented ("|") on some of my original comments ("}").  I'd
}like to respond:
}
}}
}}- I suggest that there should be a discussion of the impact of IP
}}fragmentation.  In particular: (a) performance is affected since IP packets
}}that already equal the MTU size will overflow with the addition of the AH or
}}ESP data; (b) I think there should be an implementation note that the sender of
}}an IPSP packet should make sure to put it through the fragmentation process,
}}and the destination of an IPSP packet must reassemble it before processing the
}}AH header or ESP payload.
}
}| I actually think that any mature encryption standard has to include
}| compression.  It's one of the clear superiorities of PGP over PEM.
}| But
}| I recognize that most people consider it some sort of patent quirmire.
}| Still, I hope the next generation of transformations include
}| compression.
}
}I agree that there needs to be an IP compression function.  It could be
}incorporated into an ESP transform, but it makes more sense as another payload
}type.  That way we could specify compression functions independently of
}encryption functions and could easily compose combinations of the two.

A payload type is obviously possible but seems like a lot of overhead
to me.  There certainly should be independence of compression and
encryption.  Some time ago I floated an incomplete draft that handled
this by having one header bit which, in on, meant the data was
compressed and you could look at the first byte of the "data" to
figure out how to uncompress it.  (You could have a small number of
standard compression algorithms (hopefully very small for
interoperability, like one) and a further escape value so people can
play with whatever private compression algorithms they want.)

General compression of packets is increasingly being handled by the link
hardware.

}}...
}}
}}- Page 12 of the architecture document and various other places require
}}user-oriented keying. It's not at all clear what that means for (a) systems
}}that don't have userids (e.g. Windows); (b) services that operate on behalf of
}}multiple users (e.g. nfsd); (c) systems that forward data between interfaces.
}}I think (c) is supposed to be excluded by the words "... traffic originating at
}}that system," but those words are not repeated in the several places that
}}require user-oriented keying. At the least, I think there should be some text
}}discussing these issues.
}}
}}In general, the network layer does not logically have access to user-related
}}information, and some implementations may find it difficult or impossible to
}}fulfill this requirement.  I suggest that IPSP should not (a) force
}}implementations to violate the usual separation between network layers by
}}requiring the IP layer to know the relationship between packets and users; and
}}(b) should not rule out implementations that simply can't meet this
}requirement.
}
}| Maybe the wording need to be cleared up and maybe there are
}| dedicated
}| systems where this doesn't apply but the ability to use different keys
}| on different conversations is essential.  In general, the IETF
}| concentrates on the bits on the wire while giving freedom for
}| different arrangements within "operating systems" and the like.
}| "Levels" a la OSI may be a useful model in some cases but they
}| should
}| be an aid to design, not a straight jacket.  Some conversations, like
}| NTP or routing, may be host level and servered apropriately by host
}| level keys.  But IPSEC will not have done its job if it can't stop the
}| endless stream of end to end interactive application level security
}| protocols (telnet, ftp, etc., etc.).  (Note: this remark does not
}| apply for store and forward services such as Mail, DNS, and HTTP
}| which
}| can not be adequately served by a simple "connection" oriented
}| security protocol.)  It should be possible on multi-user systems for
}| the keying to authenticate different users and processes, even if this
}| is just done in some cases by letting an application do the work
}| itself.
}
}| Seems to me that a "Windows" system should have separate keys for
}| different services it might offer so that if host A had several
}| logical connections up with Windows machine B, one for ftp, one
}| for a
}| telnet session, one for news transfer, etc., they would be separately
}| keyed.
}
}| Really, as long as a system is set up so there can be different keys,
}| they most of the complexity here is at the session keying level, not
}| in the packet formats.
}
}I suggest that this is what the drafts should say.  Not "user-oriented keying"
}but "multiple SPI's (and hence multiple keys) between pairs of hosts".  The
}question of whether the keys are user-oriented should be left to
}implementations and possibly to the key management protocol.

Fine.  I think the key management protocol has to address this to some
extent.

}}...
}}
}}- There has been a lot of discussion about whether the DES-CBC transport should
}}be required.  I respectfully submit that there is a set of organizations and
}}individuals who MUST (in a much more significant sense of "MUST") obey U.S.
}}(and other nation's) laws and who will require an engineering solution to
}}provide exportable encryption.  Either this engineering group can provide that
}}solution or someone will have to define an IPSECbis and an IPv6bis.  The risk
}}is fragmentation of standards.  Since the set of people affected by the export
}}laws is large, I argue that this working group should address the issue.
}
}| There are also lots of people that need to communicate securely
}| within
}| the United States and lots of people outside the United States
}| unaffected by the US export laws who need to communicate
}| securely.  If
}| someone want to define an insecure procotol that is freely exportable
}| from the US, they certainly can but I would recommend that anyone
}| who
}| wants to communicate securly not use such an insecure protocol.
}
}I believe in "truth in advertising": as long as a vendor (or a standards body)
}makes clear the weaknesses in any particular product or standard, then the
}people paying for the product or using the standard can make their own decision.

I sort of agree but you need at least one standard protocol so people can
talk to each other.

}In the real world, security is not binary.  There is no such thing as a "secure
}system" versus an "insecure system."  There are just degrees of security.  Let
}me give a real-world analogy:  if I buy a lock for my bicycle, I can buy one
}that can be broken with a pair of pliers.  Or I can buy one that takes a
}cutting torch to break it.  But there is no lock that can't be broken for
}sufficient money and time.  Now the market needs both types of locks, since no
}one will spend $100 for a lock for a $100 bicycle, but someone who paid $3000
}for a bicycle might well spend $100 for a lock.
}
}You might argue that ESP cannot be broken given the appropriate choice of
}encryption algorithm.  This may be true, but that just diverts any attacks to
}other aspects of the protocol or the implementations.  Just like an attacker
}faced with a really good bicycle lock will switch his attention to the chain
}used with the lock.
}
}I dislike the export rules as much as you, and I sure hope that (and will work
}to see that) they change sooner rather than later. But meanwhile, there is a
}real market for exportable IP security implementations.  Either the IETF can
}standardize it, or it can see other parties do so.  In the latter case, IETF is
}not fulfilling its proper role, in my opinion.

You aren't going to get very far, in my opinion, on this political
argument.

You are certainly right that there are different strengths of
algorithsm.  One could have any number of categories but let my use
(1) trivial, someone with experience can solve with paper and pencil,
(2) weak, breakable in a reasonable time by typical personal computer,
(3) medium, breakable in a reasonable time by resources of typical
large organization (ie, a general purpose massively parallel processor
or a large network of personal computers, (4) hard, breakable in a
reasonable time by a national cryptographic agency like NSA that can
afford special purpose hardware, etc., and (5) very hard,
computationally infeasiable to break with current knowledge.  I
realize these are very vague but they are to give an idea.  DES was in
4 but is quickly slipping into category 3.

There are lots of factors involved but since the US government
requires export licenses for all cyrpto exports and some other
countries ban all exports, there isn't any crypto algorithm that you
can guarantee can be moved across boarders.  Given that, the IETF need
to pick something, what category do you think it should choose from?
Given how widespread and standardized DES is for so many things, it
seems like a reasonable choice to me.  Restrictions on DES have been
getting weaker and weaker and quite possibly this will push the
government into removing the last ones.  You can currently usually
export full DES in binary to almost any US company or subsidiary in
almost any country.

Anyone who tries to "standardize on exportable crypto" will end up
with some junk somewhere between category 2 and 3 and I'd be happy to
help write some nice freeware to crack their stuff.  It's sure going to
be true that any decent sized government that wants to can read their
messages and the situation will probably be worse than that.

If the best the Software Publishers Association could get in their
secretly negotiated secret deal was 40 bits if the algorithm was kept
secret, what could the IETF get in open neogotations for an open
algorithm?  What's the use in standardizing on something which,
following your truth in advertising, would have to say: "By the way,
in 2 or 3 years you neighbor's kid will be able to break this in a few
hours with their desktop computer using the cyryptanaysis algorithms
developed by so-and-so as published in RFC xxx" or the like?

}| It
}| would certainly be a bad idea for the IETF to endorse such an
}| insecure
}| protocol as providing people with security.  In fact, my understanding
}| of the current situtaion is that, while individual export approval is
}| required, it is easy to get permission to export DES-CBC
}| confidentiality from the US to any US company including any US
}| subsidiary abroad unless it is in one of a few countries that are
}| specially restricated.
}
}I've gone through the process of getting an export license.  From my
}experience, I believe that the export rules are not actually published by the
}government.  And they don't apply to non-US companies.  And they apply
}differently for banking versus non-banking companies.  And they apply
}differently for different countries, even non-embargoed countries.  All in all,
}they are a significant barrier to commercial exploitation of IPSEC.

As in some other areas (see the "insider trading rules" of the SEC)
the government tries hard not to be pinned down in this area for a
number of reasons one of which is that the lack of clear rules gives
the government lots of discrition to reward and punish
companies/people.  (Other reasons might be that the full rules would
reveal too much about code breaking ability, etc.)

Since there aren't any clear rules, any attempt too negotiate them
will be hard and will lead to especially limited permissions.  40 bit
keys have generally been allowed in export for 15 years.  How much
faster have computers become in 15 years?

It's not the IETF's job to come to some secret accomodation with the
US government or any other particular government or all governments
put together.  I think its job is the somewhat self-referential one of
engineering protocols to implement the rough consensus shared vision
of the Internet community.  That includes the ability to send private
messages, credit card numbers, etc., without substantial fear of
eavesdropping.

I consider that you do not share this vision but consider the job of
the IETF to be to limit the Global Internet to whatever the US
Government happens to want to let through its border filters acording
to today's whim to be your loss.

Since software can be written in any country to meet open standards,
such as those set by the IETF, I believe, as does the IAB and IESG as
far as I can tell, that these stupid export rules should be
substantially ignored in the standards process.

}| People who want security need to use strong algorithms.  I can't see
}| why adopting a strong algorithm would cause anyone any difficult in
}| secure communications.  If they need the protocol implemented
}| some
}| place to which it can not be exported from the US, they will be
}| trivially able to get it from elsewhere.
}
}People want different degrees of security depending upon what it costs (in
}performance as well as vendor price) and what they need to protect.

Sure, but there are usually reasonable points that cover 80 to 90% and
finding simple ways to do that and avoiding much greater complexity to
try to cover 98%+ is something the IETF usually (though not always)
does.  I think DES qualifies that way.  And there is an expense in
having lots of different algoorithms.  Everyone who is serious is
going to implement DES (except maybe certain goverment agencies who
want to use their own classified stronger algorithms).

}U.S. vendors cannot sell products to international companies on the basis that
}"we'll sell you the complete package in North America, but you're on your own
}overseas."  That's a complete non-starter.

US vendors already lose sales due to these stupid export rules.  If
things get worse, they will squak louder and the probability of the
rules being liberalized will go way up.

(If in fact the international companies are US, I think they can sell
them DES in almost all countries, after going thorugh the required
paperwork.)

}| All levels of the IETF has considered this problem and the strong
}| consensus in the IPng working group, the IESG, the IETF plenary,
}| etc.,
}| etc., has consistently been that the IETF standard should require
}| strong security.
}
}I really wish I could agree with the IETF community on this point.  I see the
}arguments being made here.  I just don't think they are realistic in the real
}world.

The real world is what we make it.

Donald