draft-ietf-tls-http-upgrade-00.txt   draft-ietf-tls-http-upgrade-01.txt 
Network Working Group R. Khare
INTERNET-DRAFT Rohit Khare Internet-Draft 4K Associates / UC Irvine
<draft-ietf-tls-http-upgrade-00.txt> UC Irvine Expires: December 21, 1999 S. Lawrence
Expires May 1999 November 16, 1998 Agranat Systems, Inc.
June 22, 1999
Upgrading to TLS Within HTTP/1.1 Upgrading to TLS Within HTTP/1.1
draft-ietf-tls-http-upgrade-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its areas, all provisions of Section 10 of RFC2026.
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are working documents of the Internet Engineering
and may be updated, replaced, or obsoleted by other documents at any Task Force (IETF), its areas, and its working groups. Note that
time. It is inappropriate to use Internet-Drafts as reference material other groups may also distribute working documents as
or to cite them other than as ``work in progress.'' Internet-Drafts.
To learn the current status of any Internet-Draft, please check the Internet-Drafts are draft documents valid for a maximum of six
1id-abstracts.txt listing contained in the Internet Drafts Shadow months and may be updated, replaced, or obsoleted by other documents
Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), at any time. It is inappropriate to use Internet-Drafts as reference
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 21, 1999.
Abstract Abstract
This memo proposes a mechanism to upgrade HTTP/1.1 connections to use This memo applies the Upgrade mechanism in HTTP/1.1 to employ
Transport Layer Security (TLS). Using an Upgrade: TLS/x.y request Transport Layer Security (TLS) over an existing TCP connection. This
header would allow unsecured and secured traffic to share the same allows unsecured and secured traffic to share the same well known
port (in this case, 80). A companion document describes the current port (in this case, http: at 80 rather than https: at 443). This
practice of using a separate port for HTTP over TLS, also enables "virtual hosting," by allowing a single HTTP + TLS
<draft-ietf-tls-https-01.txt>. server to disambiguate traffic intended for several hostnames at a
single IP address.
0. Motivation This memo also clarifies how to exploit the HTTP/1.1 Upgrade
mechanism in general. It creates new IANA registries for public HTTP
status codes, and public or private Upgrade product tokens.
This memo also argues that 'https' is insufficient to discriminate
between secure and non-secure URIs, and henceforth http: alone
should be used. That is to say, both https: and port 443 could be
safely deprecated upon deployment of this mechanism.
Status Notes
This memo is intended to proceed directly to Proposed Standard,
since its functionality has been extensively debated, but not
implemented, over the last two years. It is expected to update RFC
2616.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Table of Contents
1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Client Requested Upgrade to HTTP over TLS . . . . . . . . . . 4
3.1 Requesting Upgrade When Unsecured Is Not Acceptable . . . . . 4
3.2 Requesting Upgrade When Unsecured Is Acceptable . . . . . . . 4
3.3 Server Acceptance of Upgrade Request . . . . . . . . . . . . . 5
4. Server Requested Upgrade to HTTP over TLS . . . . . . . . . . 5
4.1 Server Required Upgrade to HTTP over TLS . . . . . . . . . . . 5
4.2 Server Advertised HTTP over TLS . . . . . . . . . . . . . . . 6
5. HTTP Upgrade Usage Considerations . . . . . . . . . . . . . . 6
5.1 Upgrading across HTTP Proxies . . . . . . . . . . . . . . . . 6
6. Rationale for the use of a 4xx (client error) response code . 7
7. Rationale for the HTTP+TLS/1.0 Upgrade token . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1 HTTP Status Code Registry . . . . . . . . . . . . . . . . . . 8
8.2 HTTP Upgrade Token Registry . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9.1 Implications for the https: URI Scheme . . . . . . . . . . . . 9
References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
1. Motivation
The historical practice for deploying HTTP over SSL3[2] has
distinguished the combination from HTTP alone by a unique URI scheme
and the TCP port number. The scheme 'http' meant the HTTP protocol
alone on port 80, while 'https' meant the HTTP protocol over SSL on
port 443. Other protocols have similarly requested (and in some
cases were issued) a second well known port so that they can
distinguish the secured and unsecured modes of operation in this way
as well. Taken to its extreme, this approach in effect cuts in half
the number of available well known ports.
At the Washington DC IETF meeting in December 1997, the Applications At the Washington DC IETF meeting in December 1997, the Applications
Area Directors indicated they would like to see a mechanism for Area Directors, and the IESG broadly, reaffirmed that the practice
applying Transport Layer Security [TLS] within an HTTP connection, at of issuing parallel "secure" port numbers should be deprecated. The
the same port, instead of only being able to recommend a distinct port HTTP/1.1 Upgrade mechanism can indeed apply Transport Layer
(443) and scheme (https). IANA has already issued ten new ports for Security[5] to an HTTP connection, over the same port.
application X over TLS/SSL to date.
The TLS working group has moved forward with an extensive draft on In the nearly two years since, there has been broad acceptance of
properly implementing https (draft-ietf-tls-https-00), but there is the concept behind this proposal, but little interest in
alternate precedent for "securing" a regularly opened connection for implementing alternatives to port 443 for generic Web browsing.
SMTP and other applications (draft-hoffman-smtp-ssl, However, the Internet Printing Protocol[6], one of the first new
draft-newman-tls-imappop-03, murray-auth-ftp-ssl-00, application protocols built atop HTTP, has called for just such a
draft-ietf-ldap-ext-ldapv3-TLS-00.txt ). mechanism in order to move forward in the IETF standards process.
There has already been extensive debate on the http-wg , ietf-tls and The Upgrade mechanism also solves the "virtual hosting" problem.
ietf-apps-tls mailing lists about the advisability of permitting Rather than allocating multiple IP addresses to a single host, an
optional 'upgrades' to secure connections within the same channel, HTTP/1.1 server will use the Host: header to disambiguate the
primarily focusing on the thread of man-in-the-middle attacks. Our intended web service. As HTTP/1.1 usage has grown more prevalent,
intent here is not to engage in this debate, but merely to document a more ISPs are offering name-based virtual hosting, thus delaying IP
proposed mechanism for doing either with HTTP. Several applications address space exhaustion.
being built upon HTTP might use this mechanism, such as the Internet
Printing Protocol; we look to them for implementation guidance.
1. Introduction TLS (and SSL) have been hobbled by the same limitation as earlier
versions of HTTP: the initial handshake does not specify the
intended hostname, relying exclusively on the IP address. Using a
cleartext HTTP/1.1 Upgrade: preamble to the TLS handshake --
choosing the certificates based on the initial Host: header -- will
allow ISPs to provide secure name-based virtual hosting as well.
TLS, a/k/a SSL (Secure Sockets Layer) establishes a private end-to-end 2. Introduction
connection, optionally including strong mutual authentication, using a
variety of cryptosystems. Initially, a handshake phase uses three
subprotocols to set up a record layer, authenticate endpoints, set
parameters, as well as report errors. Then, there is an ongoing
layered record protocol that handles encryption, compression, and
reassembly for the remainder of the connection. The latter is intended
to be completely transparent. For example, there is no dependency
between TLS's record markers and or certificates and HTTP/1.1's
chunked encoding or authentication.
The need to 'secure' running connections is not merely 'running SSL Either the client or server can use the HTTP/1.1[1] Upgrade
over port 80', an early challenge for firewall developers answered by mechanism (Section 14.42) to indicate that a TLS-secured connection
Ari Luotonen's ssl-tunneling-02 draft in 1995 -- that scheme still is desired or necessary. This draft defines the "HTTP+TLS/1.0"
requires a distinct port number to activate TLS. Upgrade token and a new HTTP Reply Code, "426 Upgrade Required".
The HTTP/1.1 spec reserves CONNECT for future use, deferring to the TLS, a/k/a SSL (Secure Sockets Layer) establishes a private
more recent draft-luotonen-web-proxy-tunneling-00 proposal. This end-to-end connection, optionally including strong mutual
technique perpetuates the concept that security is indicated by a authentication, using a variety of cryptosystems. Initially, a
magic port number -- CONNECT establishes a generic TCP tunnel, so port handshake phase uses three subprotocols to set up a record layer,
number is the only way to specify the layering of TLS with HTTP authenticate endpoints, set parameters, as well as report errors.
(https) or with NTTP (snews). Then, there is an ongoing layered record protocol that handles
encryption, compression, and reassembly for the remainder of the
connection. The latter is intended to be completely transparent. For
example, there is no dependency between TLS's record markers and or
certificates and HTTP/1.1's chunked encoding or authentication.
This specification provides a procedure for either a client or
server to request that this TLS handshake phase begin on an existing
HTTP/1.1 connection.
Instead, the preferred mechanism to initiate and insert TLS in an 3. Client Requested Upgrade to HTTP over TLS
HTTP/1.1 session should be the Upgrade: header, as defined in section
14.42 of rev-03. Ideally, TLS-capable clients should add "Upgrade:
TLS/1.0" to their initial request, and TLS-capable servers may reply
with "101 Switching Protocol", complete the handshake, and continue
with the "normal" response to the original request. However, the
specification quoth:
"The Upgrade header field only applies to switching The client sends an HTTP/1.1 request with an Upgrade header field
application-layer protocols upon the existing transport-layer containing the token "HTTP+TLS/1.0".
connection."
Aside from this minor semantic difference -- invoking TLS indeed 3.1 Requesting Upgrade When Unsecured Is Not Acceptable
changes the existing transport-layer connection -- this is an ideal
application of Upgrade. This technique overlays the TLS-request on an
HTTP method; requires client-initiation, and allows servers to choose
whether or not to make the switch. Like the other examples of
TLS-enabled application protocols, the original session is preserved
across the TLS handshake; secured communications resumes with a
servers' reply.
The potential for a man-in-the-middle attack (wherein the "TLS/1.0" To complete the switch to secured operation before sending any clear
upgrade token is stripped out) is precisely the same as for mixed HTTP traffic, the client MAY use a method such as "OPTIONS*".
http/https use:
1. Removing the token is similar to rewriting web pages to change OPTIONS * HTTP/1.1
https:// links to http:// links. Host: bank.example.com
2. The risk is only present if the server is willing to vend that Upgrade: HTTP+TLS/1.0
information over an insecure channel in the first place Connection: Upgrade
3. If the client knows for a fact that a server is TLS-compliant, it
can insist on it by only connecting as https:// or by only sending The client MUST use the OPTIONS method if unsecured operation is
an upgrade request on a no-op method like OPTIONS. unacceptable.
3.2 Requesting Upgrade When Unsecured Is Acceptable
The client MAY offer to switch to secured operation during a clear
HTTP operation:
GET http://bank.example.com/acct_stat.html?749394889300 HTTP/1.1
Host: bank.example.com
Upgrade: HTTP+TLS/1.0
Connection: Upgrade
In this case, the server MAY respond to the clear HTTP operation
normally, OR switch to secured operation (as detailed in the next
section).
3.3 Server Acceptance of Upgrade Request
As specified in HTTP/1.1[1], if the server is prepared to initiate
the TLS handshake, it MUST send the intermediate "101 Switching
Protocol" response specifying the upgrade tokens it is switching to:
HTTP/1.1 101 Switching Protocols
Upgrade: HTTP+TLS/1.0
The TLS handshake bytes begin after the final CRNL of the HTTP
response.
If the TLS handshake completes, the server MUST continue with the
response to the original request. Any TLS handshake failure MUST
lead to disconnection, per the TLS error alert specification.
In the 'required upgrade' case described in Section 3.1, the client
will send the real request after the OPTIONS ("no-op") request has
completed.
4. Server Requested Upgrade to HTTP over TLS
The Upgrade header field can be used in HTTP responses to advertise
server policy.
4.1 Server Required Upgrade to HTTP over TLS
A server can indicate that a request can not be fulfilled without
TLS secured operation using the "426 Upgrade Required" status code
[see Section 6 for the rationale for why this is not a 3xx redirect
response]. The 426 response MUST include an Upgrade header field
specifying the token for the required TLS version.
HTTP/1.1 426 Upgrade Required
Upgrade: HTTP+TLS/1.0
...
The server cannot know whether or not the client is willing or able
to Upgrade. The use of 426 means that the request has failed, as any
4xx code would. This has two important implications:
1. The server SHOULD include a message body in the 426 response
which indicates in human readable form the reason for the error
and describes any alternative courses which may be available to
the user.
2. Neither the server nor the client can immediately begin the TLS
handshake -- a new request must be made, whether over the same
TCP connection or not.
If the client is capable of the protocol set specified by the server
in the Upgrade header of a 426 response, it MAY begin a
client-initiated sequence as specified in Section 3 to repeat the
request.
[Since the original request was presumably sent in the clear, the
Section 3.2 method reduce the number of round-trips in this case]
4.2 Server Advertised HTTP over TLS
As specified in [HTTP], the server MAY include an Upgrade header in
any response to indicate a willingness to switch to any
(combination) of the protocols listed. Only a 101 or 426 response
lists Upgrade tokens that MUST be used to successfully complete the
request.
5. HTTP Upgrade Usage Considerations
In the course of formalizing this mechanism, several principles of
HTTP Upgrade usage have been clarified for future users.
o Servers MUST select at most one of the offered Upgrade tokens in
the 101 Switching Protocols response.
o This implies that Upgrade tokens represent "bundles" of
functionality. Skipping a sequential upgrade to X/1.0 then to
Y/1.0 would require defining a joint XY/1.0 token, for example.
o This implies public Upgrade tokens should be managed by IANA,
according to the process in [8].
o Reliable deployment of new protocol extensions requires a
definitive failure error, "426 Upgrade Required" in this case.
This is broadly useful for any Upgrade usage.
Note that since Upgrade was only defined in HTTP/1.1 (and above),
upgraded protocols can assume persistent-connections by default.
5.1 Upgrading across HTTP Proxies
As a hop-by-hop header, Upgrade must be negotiated between each pair
of HTTP counterparties. As an end-to-end protocol, HTTP+TLS/1.0 is
only applicable across tunnels. The HTTP CONNECT method explicitly
constructed a tunnel, but it requires unique port numbers to
disambiguate services.
The following rules apply to relaying Upgrade requests:
1. Upon receipt of an Upgrade header field, a proxy server MUST
either discard all the offers, or choose to forward only those
it agrees to become a tunnel for.
2. Upon receipt of a "101 Switching Protocols" response, a proxy
server MUST become a tunnel, or report a more detailed proxy
server error.
Furthermore a caching proxy SHOULD not reply to a request with
Upgrade tokens from its cache. Clients are still advised to
explicitly include "Cache-control: no-cache" in this case.
Note that these scenarios slightly complicate diagnosis of a
426-status response. Since Upgrade: is a hop-by-hop header, a proxy
may have removed the client's original Upgrade request, while the
origin server continues to insist no offer was received.
6. Rationale for the use of a 4xx (client error) response code
Reliable, interoperable negotiation of Upgrade features requires an
unambiguous failure signal. The 426 Upgrade Required status code
allows a server to definitively state the precise protocol
extensions a given resource must be served with. Otherwise, there
would be no solution in the Section 4.1 case.
It might at first appear that the response should have been some
form of redirection (a 3xx code), by analogy to an old-style
redirection to an https: URI. User agents that do not understand
Upgrade: preclude this:
Suppose that the code 3YZ had been assigned for "Upgrade Required";
a user agent that did not recognize it would treat it as 300. It
would then properly look for a "Location" header in the response and
attempt to repeat the request at the URL in that header field.
Since it did not know to Upgrade to HTTP+TLS/1.0, it would at best
fail again at the new URL.
7. Rationale for the HTTP+TLS/1.0 Upgrade token
While TLS (and SSL) are properly ignorant of the syntax and
semantics of encapsulated, encrypted traffic, it remains
inappropriate to infer the protocol being secured by TCP port
number. To reinforce the point that the upgraded protocol is now the
composition of HTTP and TLS/1.0, we explicitly named the Upgrade
token HTTP+TLS/1.0.
Note that the version number in the product token refers to the
version of TLS employed; the version of HTTP to be used over TLS
following the switch is calculated normally, viz. per the version
compatibility rules of HTTP. [Note that while TLS is compatible with
previous versions of SSL, they do not have TLS version numbers. If
there were a backwards-compatible Upgrade, it might have specified
HTTP+SSL/3.0 instead.]
Purely HTTP-compliant extensions such as IPP will reuse
HTTP+TLS/1.0, while derivative works such as the Session Initiation
Protocol are encouraged to define their own Upgrade mechanism and
their own tokens.
8. IANA Considerations
IANA shall create registries for two name spaces, as described in
BCP 26[8]:
o HTTP Status Codes
o HTTP Upgrade Tokens
8.1 HTTP Status Code Registry
The HTTP Status Code Registry defines the name space for the
Status-Code token in the Status line of an HTTP response. The
initial values for this name space are those specified by
1. Draft Standard for HTTP/1.1[1]
2. Web Distributed Authoring and Versioning[3] [defines 420-424]
3. WebDAV Advanced Collections[4] (Work in Progress) [defines 425]
4. section Section 6 of this specification.[defines 426]
Values to be added to this name space SHOULD be subject to review in
the form of a standards track document within the IETF Applications
Area. Any such document SHOULD be traceable through statuses of
either 'Obsoletes' or 'Updates' to the Draft Standard for
HTTP/1.1[1].
8.2 HTTP Upgrade Token Registry
The HTTP Upgrade Token Registry defines the name space for product
tokens used to identify protocols in the the Upgrade HTTP header
field. Each registered token should be associated with one or a set
of specifications, and with contact information.
The Draft Standard for HTTP/1.1[1] specifies that these tokens obey
the production for 'product':
product = token ["/" product-version]
product-version = token
Registrations should be allowed on a First Come First Served basis
as described in BCP 26[8]. These specifications need not be IETF
documents or be subject to IESG review, but should obey the
following rules:
1. The registration for a given token MUST NOT be changed once
registered.
2. The registry MUST NOT register a token whose 'product' component
is the same as that of an already registered token, unless the
source of the authority for the registration is the same as the
previous registry (if company XYZ, Inc. registered "XYZ/1.0",
then no other entity should be allowed to register any token
whose product component is "XYZ" without the consent of XYZ, Inc.
An initial value in this namespace is defined in Section Section 7
of this specification.
It is NOT required that specifications for upgrade tokens be made
publically available, but the contact information for the
registration SHOULD be.
9. Security Considerations
The potential for a man-in-the-middle attack (deleting the
HTTP+TLS/1.0 upgrade token) remains the same as current, mixed
http/https practice:
o Removing the Upgrade token is similar to rewriting web pages to
change https:// links to http:// links.
o The risk is only present if the server is willing to vend that
information over both a secure and an insecure channel in the
first place.
o If the client knows for a fact that a server is TLS-compliant, it
can insist on it by only connecting as https: (currently) or by
only sending an Upgrade request with a no-op method like OPTIONS.
o Finally, as the https: specification warns, "users should
carefully examine the certificate presented by the server to
determine if it meets their expectations." -- there is no
substitute for vigilance.
Furthermore, for clients which do not actively try to invoke TLS, Furthermore, for clients which do not actively try to invoke TLS,
servers can use Upgrade: to advertise TLS compliance, too. Since servers can use Upgrade: to advertise TLS compliance, too. Since
TLS-compliance should be considered a feature of the server and not TLS-compliance should be considered a feature of the server and not
the resource at hand, it should be sufficient to send it once, and let the resource at hand, it should be sufficient to send it once, and
clients cache that fact. let clients cache that fact.
2. Potential Solution 9.1 Implications for the https: URI Scheme
Define "TLS/x.y" as a reference to the TLS specification This mechanism does not use the URI scheme name to indicate the
(draft-ietf-tls-protocol-03), with x and y bound to its major and protocol used. That is, any http: URI could be upgraded; and that
minor version numbers. Section 6.2.1 of the current draft explains why https: URIs are no guarantee the server will upgrade.
the TLS version would currently be defined as 1.0, not the actual
parameters on the wire (which is "3.1" for backwards compatibility
with SSL3).
An HTTP client may initiate an upgrade by sending "TLS/x.y" as one of Instead, the choice of what security characteristics are required on
the field-values of the Upgrade: header. The origin-server MAY respond the connection is left to the client and server. This allows either
with "101 Switching Protocols"; if so it MUST include the header party to use any information available in making this determination.
"Upgrade: TLS/x.y" to indicate what it is switching to. For example, user agents may rely on user preference settings or
information about the security of the network such as 'TLS required
on all POST operations not on my local net or VPN', and servers may
resource access rules such as 'the form on this page must be served
and submitted using TLS'.
Servers which can upgrade to TLS MAY include the header "TLS/x.y" in This also implies both parties have the option of fallback to a less
an Upgrade response header to inform the client; servers SHOULD secure mode of operation if either party cannot shift to TLS and
include such indication in response to any OPTIONS request. such unsecured operation is acceptable to both and to the human
user; this is not possible with the 'https' scheme.
Similarly, servers MAY require clients to switch to TLS first by References
responding with a new error code "418: Upgrade Required", which MUST
specify the protocol to be supported. @@ This is a change to 'core'
HTTP; if, processwise, it's too difficult to slip in a general-purpose
error code, we may have to fall-back to "418: TLS Required".
Upgrade is a hop-by-hop header (Section 13.5.1), so each intervening [1] Fielding, R.T., et. al, , "Hypertext Transfer Protocol --
proxy which supports TLS MUST also request the same version of TLS/x.y HTTP/1.1", RFC 2616, June 1999.
on its subsequent request. Furthermore, any caching proxy which
supports TLS MUST NOT reply from its cache when TLS/x.y has been
requested (although clients are still recommended to explicitly
include "Cache-control: no-cache").
Note: proxy servers may be able to request or initiate a TLS-secured [2] Rescorla, E.K., "HTTP Over TLS", Internet-Draft (Work In
connection, e.g. the outgoing or incoming firewall of a trusted Progress), September 1998.
subnetwork.
3. Next Steps [3] Goland, Y.Y., Whitehead, E.J., et. al, , "Web Distributed
Authoring and Versioning", RFC 2518, February 1999.
While there is formal interest in promulgating a scheme for HTTP/TLS [4] Slein, J., Whitehead, E.J., et. al, , "WebDAV Advanced
without allocating a new port number, implementations have been Collections Protocol", Internet-Draft (Work in Progress), June
scarce. We cannot predict what might trigger adoption of this 1999.
proposal.
Note: The Mandatory extension scheme for HTTP is another mechanism, [5] Dierks, T., Allen, C., "The TLS Protocol", RFC 2246, January
though arguably less aprropriate, since TLS does not modify the 1999.
semantics of HTTP itself. TLS would be using Upgrade for its stated
purpose -- to switch to an entirely different protocol.
This document is available at http://www.ics.uci.edu/~rohit/http-tls. [6] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet
Printing Protocol/1.0: Encoding and Transport", RFC 2565, April
1999.
3.1 Open Issues [7] Rose, M.T., "Writing I-Ds and RFCs using XML", April 1999.
There have been some questions about how to continue to resolve https: [8] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA
URLs with the scheme postulated here. There is a default assumption in Considerations Section in RFCs", BCP 26, October 1998.
many products that https and http:443 are equivalent.
Similarly, when resolving a mixture of secured and unsecured URLs from Authors' Addresses
the same site, some might postulate the need to "downgrade" the
connection. We suggest simply reopening the HTTP connection without
TLS.
4. Acknowledgments Rohit Khare
4K Associates / UC Irvine
3207 Palo Verde
Irvine, CA 92612
US
Thanks to Paul Hoffman for his work on the STARTTLS command extension Phone: +1 626 806 7574
for ESMTP. Thanks to Roy Fielding for assistance with the rationale EMail: rohit@4K-associates.com
behind Upgrade: and OPTIONS. URI: http://www.4K-associates.com/
Scott Lawrence
Agranat Systems, Inc.
5 Clocktower Place
Suite 400
Maynard, MA 01754
US
5. References Phone: +1 978 461 0888
EMail: lawrence@agranat.com
URI: http://www.agranat.com/
1. http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q4/0495.html Appendix A. Acknowledgments
2. http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-rev-03.txt
3. http://www.ietf.org/internet-drafts/draft-ietf-tls-https-00.txt Thanks to:
4. http://www.imc.org/ietf-apps-tls/draft-hoffman-smtp-ssl o Paul Hoffman for his work on the STARTTLS command extension for
5. http://www.ietf.org/internet-drafts/draft-newman-tls-imappop-03.txt ESMTP.
6. http://www.consensus.com/ietf-tls/murray-auth-ftp-ssl-00.txt o Roy Fielding for assistance with the rationale behind Upgrade:
7. http://www.ics.uci.edu/pub/ietf/http/ and its interaction with OPTIONS.
8. http://www.consensus.com/ietf-tls/ o Eric Rescorla for his work on standardizing the existing https:
9. http://www.imc.org/ietf-apps-tls/ practice to compare with.
10. http://www.pwg.org/ipp/index.html o Marshall Rose, for the xml2rfc document type description and
11. http://www.consensus.com/ietf-tls/ssl-tunneling-02.txt tools.
12. http://www.ietf.org/internet-drafts/draft-luotonen-web-proxy-tunneling-00 o Jim Whitehead, for sorting out the current range of available
.txt HTTP status codes.
13. http://www.consensus.com/ietf-tls/tls-protocol-03.txt
14. http://www.ics.uci.edu/~rohit/http-tls Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/