A mighty fortress is our PKI, Part II

[Nicolas Williams]

On Wed, Jul 28, 2010 at 02:41:35PM -0400, Perry E. Metzger wrote:
> On the other edge of the spectrum, many people now use quite secure
> protocols (though I won't claim the full systems are secure --
> implementation bugs are ubiquitous) for handling things like remote
> login and file transfer, accessing shared file systems on networks,
> etc., with little to no knowledge on their part about how their
> systems work or are configured. This seems like a very good thing. One
> may complain about many issues in Microsoft's systems, for example,
> but adopting Kerberos largely fixed the distributed authentication
> problem for them, and without requiring that users know what they're
> doing.

Hear, hear!  But... great for corporate networks, not quite for
Internet-scale, but a great example of how we can make progress when we
want to.

> (I am reminded of the similar death-by-complexity of the IPSec
> protocol's key management layers, where I am sad to report that even I
> can't easily configure the thing. Some have proposed standardizing on
> radically simplified profiles of the protocol that provide almost no
> options -- I believe to be the last hope for the current IPSec suite.)

IPsec is a great example of another kind of failure: lack of APIs.
Applying protection to individual packets without regard to larger
context is not terribly useful.  Apps have no idea what's going on, if
anything, in terms of IPsec protection.  Worse, the way in which IPsec
access control is handled means that typically many nodes can claim any
given IP address, which dilutes the protection provided by IPsec as the
number of such nodes goes up.  Just having a way to ask that a TCP
connection's packets all be protected by IPsec, end-to-end, with similar
SA pairs (i.e., with same peers, same transforms) would have been a
great API to have years ago.

The lack of APIs has effectively relegated IPsec to the world of VPN.

Nico
-- 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com