Re: Missing requirements

In message <9605221722.AA01417@mordred.sware.com>, Charles Watt writes:
> 
> You missed the entire point of my message, which had nothing to do with
> any specifics of our Hannah product.  I will reiterate as succinctly
> as I can that one point, and then address individual comments below.
> 
> THE POINT:
> 
> 	Integrating key management, authentication and data security 
> 	services into a single, in-band protocol is a BAD idea for a
> 	generic transport layer security protocol.  It effectively 
> 	eliminates architectures that are capable of providing higher 
> 	security and assurance.  It also ensures redundant key management 
> 	facilities when other services such as IPSEC are deployed.

Sorry for missing your point.  It was not apparent from the original
message.  It appears you're trying to say is that you want a more
orthogonal design.  That's not entirely unreasonable.  Certainly a
better system results when good protocol design is coupled with good
systems engineering.  (Also, there's no need to SHOUT.)

I have no wish to attack Hannah -- I was in part confused by a
protocol specification document that described all these extra
protocol families as if they were relevent and intended to be
supported (if not yet).  If you say that family C is irrelvant, fine.
Personally, I don't like documents that try to do too many things at
once: discussing bad, discarded alternatives like a high level
[pre-]design document or a survey article, as well as talking about
state diagrams and wire formats like an implementer's guide.  But
those are my biases.

> [...]  The point again is simply:
> "Can the protocol support high security, high assurance implementations?"
> If not, it is not a suitably generic protocol.  The current drafts of SSL 
> and PCT.

Cut-n-pasted from the proposed charter:

> The TLS working group is a focused effort on providing security
> features at the transport layer, rather than general purpose security
> and key management mechanisms.  The standard track protocol
> specification will provide methods for implementing privacy,
> authentication, and integrity above the transport layer.

And one of my points was that the TLS WG is not the IPSEC WG, nor is
is it spec'ing out a fully generic, do everything protocol.  Certainly
non-repudiation is outside the scope of TLS -- nobody has mentioned
signing every message yet AFAIK.  Hannah's scope includes this (as an
option); TLS's does not.

The protocols that you fault with being too integrated /
insufficiently generic, e.g., SSL or PCT or STLP, however, do not
necessarily dictate system design.  They certainly include necessary
protocol version numbers etc to provide compatibility, as well as the
numbering for crypto primitive negotiation/selection.  If the claim is
that key exchange/management protocols evolve too quickly and that an
upgrade path should exist, then the versioning will already take care
of that at the wire-level, and as long as the implementations are
relatively clean upgrading should not pose great difficulties.

If what you're looking for is to explicitly name the record layer one
protocol and the key exchange/management layer another protocol,
that's fine.  It may help to clarify thinking to separate these even
more explicitly.  A security protocol, by any other name, resists the
same attacks.

Regarding the fact that DNS is not secure, we seem to have different
opinions based on that same fact.  You seem to want everybody to use
the Hannah-provided certified namespace and nothing else.  I think
that's impractical.

I argue that because DNS is not secure, something needs to be done in
order to link the namespaces together.  We have the certified names in
one namespace, and DNS names in another.  If the Hannah protocols were
to be used, the application (e.g., Web browsers) will speak in one
namespace (DNS names), but the secured transport that Hannah provides
will talk in another (fully certified names).  If I give you an URL
(which contains a DNS name) and your browser ends up connecting to a
fully certified agent, that agent may or may not have the expected
correspondence to the DNS name.  How the DNS name is "resolved" to the
Hannah certified name must be verified.  If your applications are
Hannah-aware and deal only with certified names, fine.  If your
application thinks in one namespace that doesn't trivially map into
the Hannah-supplied certified namespace, then we've still got a
problem.

To provide security with application transparency, after the
authentication protocol runs -- which authenticates in the certified
namespace -- the implementation should try to make sure that the name
supplied by the user -- which is a DNS name or a raw IP address -- has
something to do with the authenticated peer.

-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 16:00:28 UTC