[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on latest IPSP drafts
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.
}- The definition of "authentication" and "integrity" on page 1 of the
}architecture draft implies that the former is a superset of the latter. This
}is inconsistent with the usual terminology, which treats these as distinct
}concepts.
| But isn't the usual terminology wrong in this regard? How can you
| determine that a message is authentic if you can't tell that it has
| been changed (don't have integrity)?
I've re-read Phil Rogaway's comments on this point and I think I agree
with him.
}...
}
}- 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.
}...
}
}- 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.
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.
| 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.
| 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.
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.
| 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.