Re: Missing requirements

In message <199605221509.LAA06555@argon.ncsc.mil>, David P. Kemp writes:
> 
> I believe the issue is not whether the platform / OS (it's not just
> an OS question) will be replaced with something "secure", it is whether
> an IETF-standardized protocol should be designed in such a manner as
> to facilitate the development of secure systems, as opposed to relying
> on each separate application to design and incorporate it's own security.

Perhaps I'm being dense, but I don't see how having -any- security
protocol standardized by IETF would mean relying on every separate app
to design and incorporate its own security.

As long as (minimally) version numbers exist to provide an on-wire
upgrade path and with reasonable API design, we'd have to at most
relink the apps.  Unless, of course, the standardized protocol
actually fails to provide any security properties whatsoever.

The only other senses you might have meant by this that I can think of
is if the protocol can not be implemented in a completely application
transparent way, resulting in the app having to be modified.  Are you
arguing for having some mechanism to enforce the mandatory use of the
TLS protocol?  The use of dynamic libraries or streams modules or DLLs
or whatever to separate the protocol processing from the core of the
app?

> Regardless of whether Hannah's *implementation* of D-H is subject to
> MITM attacks, D-H can be designed to resist known protocol attacks.
> See, for example, the draft ANSI X9.42 - 1996 "Establishment of
> Symmetric Algorithm Keys using Diffie-Hellman", available from the
> American Bankers Association.

It's well known how to do D-H w/ auth in a protocol: exchange
signatures of the protocol messages received after the D-H key has
been exchanged, so you know what you think you sent was actually
received by the intended recipients (via certs on sig keys).  I was
not talking about an implementation of D-H but a protocol design which
uses D-H in an unsound way.  I certainly did not examine any code.
Maybe this is more of a terminology problem.

Any protocol specification document that describes an unsound protocol
shakes my faith in the entire document.  So I am extremely glad to
hear from Charles that this particular protocol design was actually
discarded and that this was actually a writing/communication problem.

> [ ... ]
> But the key management protocol (Hannah's PAKMP, IPSEC's ISAKMP) is
> big, complicated, and requirements are rapidly evolving.  It makes
> sense to fully de-couple the two protocols so that:
>  1) a single KMP can be shared by all network layers - IP,
>     transport, and application,
>  2) evolution in key management technology can be accommodated
>     without replacing all the software that has it hardwired in, and
>  3) each application can be a *lot* smaller.

 From an architectural point of view, it is nice to fully decouple
things.  From a design-for-performance point of view, fully decoupling
requires careful study of the interface between the two -- it would
certainly be impossible to handle pre-encrypted, pre-MACed
widely-distributed data with a naive interface.  It is possible to
having a nice, layered approach that still permits such speedups?  I
think so.

I haven't been arguing against decoupling.  I just noticed what
appeared to be a flaw in a Hannah protocol, pointed to the protocol
document by what appeared to be a statement that Hannah incorporated a
design that was exemplary of the sort of separation for which we
should strive.

> Modifying the network stack on Unix hosts only requires kernel
> modifications (and source) if you're using an obsolete Unix.  If
> the kernel uses Streams networking (Solaris, for example) the
> application can just push another Streams module onto the stack.

Installing a streams module require root access.  Certainly heretofore
browser installation had not required such, so "just" pushing another
Streams module isn't necessarily something that we can mandate.
Furthermore, last I heard Netscape provided a Linux version of
Navigator, and while users of these systems are more likely to have
root access, Linux/*BSD does not have Streams.

-bsy

--------
Bennet S. Yee		Phone: +1 619 534 4614	    Email: bsy@cs.ucsd.edu

Web:	http://www-cse.ucsd.edu/users/bsy/
USPS:	Dept of Comp Sci and Eng, 0114, UC San Diego, La Jolla, CA 92093-0114

Received on Wednesday, 22 May 1996 20:10:32 UTC