Re: SSL Tunneling; Informational RFC; Last call?

Jim Whitehead <ejw@ics.uci.edu> wrote:
>On Friday, September 12, 1997 7:04 PM, Ari Luotonen 
>[SMTP:luotonen@netscape.com] wrote:
>>
>> I would like to issue a Last Call for the SSL Tunneling spec (included
>> below), in order to move it into the Informational RFC state.  The
>> spec has remained virtually unchanged for two I-D rounds (current
>> draft-luotonen-ssl-tunneling-03.txt expires on 9/26/97), so I believe
>> there is consensus and it accurately describes the current behaviour.
>>
>
>Even though this draft is intended for Informational status only, I think 
>it would be worthwhile to add a short section stating that SSL technology 
>is affected by Netscape's  patent on SSL in the US -- US Patent number 
>5,657,390.
>
>The patent is entitled "Secure socket layer application program apparatus 
>and method", and is available at:
>
><http://patent.womplex.ibm.com/details?patent_number=5657390>.
>
>Since this isn't a standards track document, my understanding is that the 
>existence of this patent will not affect the distribution of this draft as 
>an Informational RFC.

	I'm concerned that possibly inadequate familiarity with IETF
terminology and procedural issues is yielding misunderstandings about
Ari's draft, and its actual intentions.

	Although the impetus for the CONNECT method was to tunnel
SSL encrypted communications through proxies, it is a general HTTP
method, and the actual text of the draft indicates intention for it
to proceed on stardards tract.  The *method* is not proprietary, and
Ari offers a patch for implementing CONNECT with the CERN proxy.
It works, beautifully, for any protocol the proxy is configured to
permit, and with the appropriate access regulation that is normally
associated with true proxies.  CONNECT is as solid, IMHO, as the GET,
HEAD and POST methods, and so I hope it does proceed on standards
track, with the appropriate modifications in the draft (including
its title) to make that possible, and to make clear that tunneling
of SSL encrypted communications with https and snews origin servers
is simply an instance of its use.

	To give you concrete implementation examples, the Lynx
ftp gateway is, of course, optimized for character cell terminals
and braille or speech interfaces, whereas essentially all
contemporary proxy ftp gateways are geared toward GUIs.  When
a Lynx user is "trapped" behind a firewall, the CONNECT method,
if implemented in that proxy with ftp tunneling authorized,
Lynx's own ftp gateway could be used instead of whatever ftp
gateway the proxy offers.  I suspect many GUI users similarly
would prefer to use their favorite browser's own gateway in
such cases (if the proxy is not a vendor match with essentially
the same gateway).

	Lynx also has a finger and cso/qi/ph gateway, often not
available in proxies, that could be used behind a firewall if the
proxy supported CONNECT and those protocols were authorized.

	Does anyone familiar with the CONNECT method have a serious
objection to its being considered as a standards track method, not
necessarily for the impending HTTP/1.1 RFC, but eventually to be
merged into an HTTP RFC?

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Friday, 19 September 1997 15:16:05 UTC