TLS document modularity

> From: Win Treese <treese@OpenMarket.com>
> Subject: Closing on shared-key authentication
> 
> At this point, I propose that we adopt the proposed
> modifications for the TLS draft. As always, I am happy
> to hear comments either on the list or in direct mail.

No comments.


> In addition, if there are other burning issues for substantive
> changes, please let me know about them now.

I would like to see the first product of this working group separated
into two RFC documents, one defining the Record Layer, and the other
defining the Handshake Protocol.  This follows existing practice of the
IP Security working group which has separate documents for the security
transforms (AH and ESP) and for the Internet Key Management Protocol
(IKMP).  Separating the TLS standard into two components allows a
useful separation of function, so that issues affecting only one
component do not hold up progress on the other.  The great shared
secret debate (although it pales in comparison to the IPsec IKMP
debate :-) is a case in point.

The other benefit is that a standard Record Layer format could be
reused in other applications.  Several come to mind: RADIUS (an
authentication protocol for Network Access Servers (NASs)) has
abysmal security between the NAS and the authentication server - the
ink isn't even dry on RADIUS yet and the WG is already working on
requirements (including security) for RADIUS-NG.  Cisco just released
an I-D for TACACS+, a different (and IMO somewhat more mature) protocol
which addresses the same application space.  A generic TLS record
format could be used by the NAS market even if their keying requirements
differ from the Web market.

Jeff Schiller has also begun a(nother) Telnet security initiative,
this time driven by a pressing need to enable secure remote
administration of the Internet infrastructure.  A TLS record component
could be more easily incorporated into the Telnet authentication/
encryption framework than could full SSL 3.

This is, after all, the Transport Layer Security group, not just Web
Connection Security.  At present, I'm not proposing any changes to the
SSL 3.0 baseline protocol itself, just proposing that the existing
protocol be documented in a more modular fashion.  There is some work
to be done, such as defining the minimum sufficient connection state
data - server and client random don't belong in connection state, but
compression, encryption, and MAC methods do, as do byte counts for data
protected by the current encryption keys and MAC secrets).  But
cleanly specifying the keying/transform interface now will pay off
in reduced development effort later.

Received on Monday, 7 October 1996 11:56:05 UTC