Re: TLS Draft Charter?

> From: Win Treese <treese@openmarket.com>
>
>   ... The SSL, PCT and SSH protocols are
> examples of mechanisms of establishing a secure channel for general
> purpose or special purpose Internet applications running over a
> reliable transport, usually TCP.

The SecureWare HannaH protocol (http://www.secureware.com/products/hanna/)
is another example of a suitable mechanism, one which may have something
to offer this group.  I believe the SecureWare folks plan to participate
here, but even if they don't, the above is good reading material.

With regard to TCP, both HannaH and the newly-released PCT 2.0 spec
address unreliable transport (UDP).  I mildly believe that this WG should
confine itself to reliable connection-oriented protocols and that UDP
security should be provided by IPSEC technology.  But either way, the
charter should contain an explicit statement that datagram security is,
or is not, a goal/requirement/appropriate-topic-of-discussion.


> Goals and Milestones
>
> April 96 Agreement on charter and issues in current draft.
>
> July 96  Final draft for Secure Transport Layer Protocol ("STLP")
>
> Nov 96   Working group "Last Call"
>
> Dec 96   Offer to IESG for IETF "Last Call"

I see a lot of handwaving between the April and July milestones :-).
After all, we are dealing with three or four entrenched existing
implementations, not writing a spec ab initio.  It may be useful to
write a "Requirements" document that defines the goals and non-goals
in greater detail than can be done in the charter, against which
the various proposals can be evaluated.


> From: Rodney Thayer <rodney@sabletech.com>
> 
> I think it is important to address the issue of migration from existing
> protocols to the charter.  Even if what ends up getting produced contains an
> explicit claim it does not address migration. I do not think it should be
> silently ignored.

Agreed.  The TLS candidate sponsors should provide some guidance to the WG
as to how they intend to address migration.  In the absense of such
statements, the charter should include the explicit claim that it does
not address migration.  In any case, the result should be a single
coherent STLP, not a mishmash framework that supports backward
compatibility with everything that's out there now.


> From: Christopher Allen <ChristopherA@consensus.com>
> 
> Does the scope of the TLS working group include interaction with firewalls
> and/or proxy servers? I think it should, as I think it will be difficult to
> have a generic (i.e. non-protocol based) solution to this problem.
> 
> If scope includes this, it should be reflected in the draft charter.

Strongly agreed.  One of the problems is defining exactly what controls
proxies are expected to place on TLS connections: punch a hole to allow
all traffic on specific ports? authenticate one or both endpoints? have
access to the full encrypted record stream? (my suggestion is NO!, both,
and no, respectively.)


> From: timd@consensus.com (Tim Dierks)
> 
> I'd like to see the group address issues surrounding disambiguating secure
> sessions from insecure ones. For example, issues have been raised on the
> SSL-talk list about whether using different port numbers is an appropriate
> method of distinguishing protocols which are identical except for their use
> (or lack thereof) of a secure transport layer. Given the limited number of
> "trusted" port numbers (1024 or so), it seems that multiplying the number
> of services by the number of possible transports might quickly lead to a
> crisis. We should at least discuss methods of sharing ports between secure
> and insecure sessions.

Agreed.  If it is technically feasible to support the distinction
without disrupting existing TCP implementations, it should be done.
(A browser should be able to connect to an existing, unmodified nntp
server on port 119, somehow attempt to establish a secure connection,
and if that fails fall back to a normal TCP connection.  A TLS-modified
nntp server on port 119 would be configurable to either fall back or
refuse to connect to unmodified clients.)

I believe that neither SSH nor HannaH use reserved ports, but I don't
know if either of them interoperate with unmodified peers.  Following
the IETF principle of "rough consensus and working code", if none of
the existing implementations interoperate with standard peers on standard
port numbers, then that shouldn't be a requirement of this WG. Otherwise
it should.

Received on Wednesday, 10 April 1996 13:19:14 UTC