Thanks for the info.
Any idea when the draft that we are really waiting for might be ready
then,
and is that aimed for the standards track or not?
Carl-Uno
> -----Original Message-----
> From: Win Treese [mailto:treese@OpenMarket.COM]
> Sent: Saturday, August 22, 1998 8:15 AM
> To: IETF Transport Layer Security WG
> Cc: ipp@pwg.org
> Subject: IPP> RE: HTTP/TLS draft
>
>
> Carl-Uno,
>
> Eric's draft mainly applies to HTTP 1.0 as a compatibility mechanism.
> There's a separate effort underway (drafted by Rohit Khare) to define
> the use of TLS with HTTP 1.1. The Application Area Director rules
> apply to the HTTP 1.1 work, but not to HTTP 1.0, since we are
> stuck with the way SSL is currently used with HTTP 1.0.
>
> - Win Treese
>
> At 05:12 AM 8/22/98 -0700, Manros, Carl-Uno B wrote:
> >Eric,
> >
> >Thanks for getting this out, even if it did not make the Chicago
> >deadline.
> >
> >As you know, we have been intending to apply this profile for the IPP
> >protocol.
> >
> >However, we still seem to have a certain disconnect here. The two
> >Application Area Directors recently brought to paper a
> number of rules
> >for how to use security in applications run over HTTP 1.1.
> >
> >Here is the title and a quote from that document:
> >
> >---
> >
> >On the use of HTTP as a Substrate for Other Protocols
> ><draft-iesg-using-http-00.txt>
> >5 August 1998
> >
> >Note that the convention of appending an "s" to the URL scheme to
> >mean "use TLS or SSL" (as in "http:" vs "https:") is
> nonstandard and
> >should not be propagated. For most applications, a single
> "use TLS or
> >SSL" bit is not sufficient to adequately convey the
> information that a
> >client needs to authenticate itself to a server, even
> if it has the
> >proper credentials. Authentication or other
> connection setup
> >information should be communicated in URL parameters, rather
> than in the
> >URL prefix.
> >
> >-----
> >
> >I know that they have also stated elsewhere that they do not
> want to see
> >a special port # such as 443 useed for security.
> >
> >Is there any chance that we can overcome these differences?
> >
> >Carl-Uno
> >
> >> -----Original Message-----
> >> From: EKR [mailto:ekr@terisa.com]
> >> Sent: Wednesday, August 19, 1998 8:53 AM
> >> To: IETF Transport Layer Security WG
> >> Subject: HTTP/TLS draft
> >>
> >>
> >> First off, I want to apologize for my failure to make the draft
> >> deadline. I've been real busy, but I still should have made it.
> >>
> >> That said, here's a slightly touched up version of the HTTP/TLS
> >> draft. I think it should fix the wildcard issue (no longer
> references
> >> PKIX for wildcarding) and align more closely with Keith Moore's
> >> suggestions for handling name matching.
> >>
> >> Comments welcome,
> >>
> >> - -Ekr
> >>
> >> - ----
> >>
> >>
> E. Rescorla
> >> INTERNET-DRAFT Terisa
> Systems, Inc.
> >> <draft-ietf-tls-https-02.txt> September 1998
> (Expires March-99)
> >>
> >> HTTP Over TLS
> >>
> >> Status of this Memo
> >>
> >> This document is an Internet-Draft. Internet-Drafts are working
> >> documents of the Internet Engineering Task Force
> (IETF), its areas,
> >> 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
> >> and may be updated, replaced, or obsoleted by other
> >> documents at any
> >> time. It is inappropriate to use Internet-Drafts as reference
> >> material or to cite them other than as ``work in progress.''
> >>
> >> To learn the current status of any Internet-Draft,
> please check the
> >> ``1id-abstracts.txt'' listing contained in the
> >> Internet-Drafts Shadow
> >> Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
> >> munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
> >> ftp.isi.edu (US West Coast).
> >> Abstract
> >>
> >> This memo describes how to use TLS to secure HTTP
> connections over
> >> the Internet. Current practice is to layer HTTP over SSL
> >> (the prede-
> >> cessor to TLS), distinguishing secured traffic from
> >> insecure traffic
> >> by the use of a different server port. This document
> documents that
> >> practice using TLS. A companion document describes a
> >> method for using
> >> HTTP/TLS over the same port as normal HTTP.
> >>
> >> 1. Introduction
> >>
> >> HTTP [RFC2068] was originally used in the clear on the Internet.
> >> However, increased use of HTTP for sensitive applications has
> >> required security measures. SSL, and its successor TLS
> [TLS] were
> >> designed to provide channel-oriented security. This document
> >> describes how to use HTTP over TLS.
> >>
> >> 1.1. Discussion of this Draft
> >>
> >> This draft is being discussed on the "ietf-apps-tls"
> >> mailing list. To
> >> subscribe, send a message to:
> >>
> >> ietf-apps-tls-request@imc.org
> >>
> >> with the single word
> >>
> >>
> >>
> >> Rescorla
> >> [Page 1]
> >> Internet-Draft HTTP Over TLS
> >>
> >>
> >>
> >> subscribe
> >>
> >> in the body of the message. There is a Web site for the
> >> mailing list
> >> at <http://www.imc.org/ietf-apps-tls/>.
> >>
> >> 1.2. Requirements Terminology
> >>
> >> Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD",
> "SHOULD NOT" and
> >> "MAY" that appear in this document are to be interpreted
> >> as described
> >> in [RFC2119].
> >>
> >> 2. HTTP Over TLS
> >>
> >> Conceptually, HTTP/TLS is very simple. Simply use HTTP
> >> over TLS pre-
> >> cisely as you would use HTTP over TCP.
> >>
> >> 2.1. Connection Initiation
> >>
> >> The agent acting as the HTTP client should also act as the TLS
> >> client. It should initiate a connection to the server on the
> >> appropriate port and then send the TLS ClientHello to
> begin the TLS
> >> handshake. When the TLS handshake has finished. The
> client may then
> >> initiate the first HTTP request. All HTTP data MUST be
> sentas TLS
> >> "application data". Normal HTTP behavior, including
> >> retained connec-
> >> tions should be followed.
> >>
> >> 2.2. Connection Closure
> >>
> >> TLS provides a facility for secure connection closure.
> When a valid
> >> closure alert is received, an implementation can be
> assured that no
> >> further data will be received on that connection. TLS
> implementa-
> >> tions MUST initiate an exchange of closure alerts
> before closing a
> >> connection. A TLS implementation MAY, after sending a
> >> closure alert,
> >> close the connection without waiting for the peer to send
> >> its closure
> >> alert, generating an "incomplete close". Note that an
> >> implementation
> >> which does this MAY choose to reuse the session. This
> >> SHOULD only be
> >> done when the application knows (typically through
> detecting HTTP
> >> message boundaries) that it has received all the message
> >> data that it
> >> cares about.
> >>
> >> As specified in [TLS], any implementation which receives a
> >> connection
> >> close without first receiving a valid closure alert (a
> "premature
> >> close") MUST NOT reuse that session. Note that a premature
> >> close does
> >> not call into question the security of the data already
> >> received, but
> >> simply indicates that subsequent data might have been truncated.
> >> Because TLS is oblivious to HTTP request/response
> boundaries, it is
> >> necessary to examine the HTTP data itself (specifically
> >> the Content-
> >>
> >>
> >>
> >> Rescorla
> >> [Page 2]
> >> Internet-Draft HTTP Over TLS
> >>
> >>
> >> Length header) to determine whether the truncation
> >> occurred inside a
> >> message or between messages.
> >>
> >> 2.2.1. Client Behavior
> >>
> >> Because HTTP uses connection closure to signal end of
> server data,
> >> client implementations MUST treat any premature closes as
> >> errors and
> >> the data received as potentially truncated. Two cases
> in particular
> >> deserve special note:
> >>
> >> A HTTP response without a Content-Length header.
> >> Since data length in
> >> this situation is signalled by connection close a
> >> premature close
> >> generated by the server cannot be distinguished
> >> from a spurious
> >> close generated by an attacker.
> >>
> >> A HTTP response with a valid Content-Length header
> >> closed before
> >> all data has been read. Because TLS does not
> >> provide document oriented protection, it is
> >> impossible to determine whether the server has
> >> miscomputed the
> >> Content-Length or an attacker has truncated the
> connection.
> >>
> >>
> >> When encountering a premature close, a client SHOULD
> treat as com-
> >> pleted all requests for which it has received as much data
> >> as speci-
> >> fied in the Content-Length header.
> >>
> >> A client detecting an incomplete close SHOULD recover
> >> gracefully. It
> >> MAY resume a TLS session closed in this fashion.
> >>
> >> Clients MUST send a closure alert before closing the connection.
> >> Clients which are unprepared to receive any more data MAY
> >> choose not
> >> to wait for the server's closure alert and simply close
> the connec-
> >> tion, thus generating an incomplete close on the server side.
> >>
> >> 2.2.2. Server Behavior
> >>
> >> RFC2068 permits an HTTP client to close the connection
> at any time,
> >> and requires servers to recover gracefully. In
> particular, servers
> >> SHOULD be prepared to receive an incomplete close from
> the client,
> >> since the client can often determine when the end of
> >> server data is.
> >> Servers SHOULD be willing to resume TLS sessions closed in this
> >> fashion.
> >>
> >> Implementation note: In HTTP implementations which do
> not use per-
> >> sistent connections, the server ordinarily expects to be
> >> able to sig-
> >> nal end of data by closing the connection. When
> Content-Length is
> >> used, however, the client may have already sent the
> >> closure alert and
> >> dropped the connection.
> >>
> >>
> >>
> >>
> >> Rescorla
> >> [Page 3]
> >> Internet-Draft HTTP Over TLS
> >>
> >>
> >> Servers MUST attempt to initiate an exchange of closure
> alerts with
> >> the client before closing the connection. Servers MAY
> >> close the con-
> >> nection after sending the closure alert, thus
> generating an incom-
> >> plete close on the client side.
> >>
> >> 2.3. Port Number
> >>
> >> The first data that an HTTP server expects to receive from
> >> the client
> >> is the Request-Line production. The first data that a TLS
> >> server (and
> >> hence an HTTP/TLS server) expects to receive is the
> >> ClientHello. Con-
> >> sequently, common practice has been to run HTTP/TLS
> over a separate
> >> port in order to distinguish which protocol is being used. When
> >> HTTP/TLS is being run over a TCP/IP connection, the
> default port is
> >> 443. This does not preclude HTTP/TLS from being run over another
> >> transport. TLS only presumes a reliable connection-oriented data
> >> stream.
> >>
> >> 2.4. URI Format
> >>
> >> HTTP/TLS is differentiated from HTTP URIs by using the
> >> 'https' proto-
> >> col identifier in place of the 'http' protocol identifier.
> >> An example
> >> URI specifying HTTP/TLS is:
> >>
> >> https://abc.com:80/~smith/home.html
> >>
> >>
> >> 3. Endpoint Identification
> >>
> >> 3.1. Server Identity
> >>
> >> In general, HTTP/TLS requests are generated by
> dereferencing a URI.
> >> As a consequence, the hostname for the server is known to
> >> the client.
> >> If the hostname is available, the client MUST check it
> against the
> >> server's identity as presented in the server's
> Certificate message,
> >> in order to prevent man-in-the-middle attacks.
> >>
> >> If the client has external information as to the expected
> >> identity of
> >> the server, the hostname check MAY be omitted. (For instance, a
> >> client may be connecting to a machine whose address and
> >> hostname are
> >> dynamic but the client knows the certificate that the
> server will
> >> present.) In such cases, it is important to narrow the scope of
> >> acceptable certificates as much as possible in order to
> prevent man
> >> in the middle attacks. In special cases, it may be
> appropriate for
> >> the client to simply ignore the server's identity, but
> it must be
> >> understood that this leaves the connection open to
> active attack.
> >>
> >> If a subjectAltName extension of type dNSName is
> present, that MUST
> >> be used as the identity. Otherwise, the (most specific)
> Common Name
> >>
> >>
> >>
> >> Rescorla
> >> [Page 4]
> >> Internet-Draft HTTP Over TLS
> >>
> >>
> >> field in the Subject field of the certificate MUST be
> >> used. Although
> >> the use of the Common Name is existing practice, it is
> >> deprecated and
> >> Certification Authorities are encouraged to use the
> >> dNSName instead.
> >>
> >> Matching is performed using the matching rules
> specified by [PKIX].
> >> If more than one identity of a given type is present in
> >> the certifi-
> >> cate (e.g. more than one dNSName name, a match in any one
> >> of the set
> >> is considered acceptable.) Names may contain the wildcard
> >> character *
> >> which is considered to match any single domain name
> >> component or com-
> >> ponent fragment. E.g. *.a.com matches foo.a.com but not
> >> bar.foo.a.com. f*.com matches foo.com but not bar.com.
> >>
> >> If the hostname does not match the identity in the
> >> certificate, user
> >> oriented clients MUST either notify the user (clients
> MAY give the
> >> user the opportunity to continue with the connection in
> >> any case) or
> >> terminate the connection with a bad certificate error. Automated
> >> clients MUST log the error to an appropriate audit log (if
> >> available)
> >> and SHOULD terminate the connection (with a bad
> certificate error).
> >> Automated clients MAY provide a configuration setting
> that disables
> >> this check, but MUST provide a setting which enables it.
> >>
> >> 3.2. Client Identity
> >>
> >> Typically, the server has no external knowledge of what
> >> the client's
> >> identity ought to be and so checks (other than that the
> >> client has a
> >> certificate chain rooted in an appropriate CA) are not
> >> possible. If a
> >> server has such knowledge (typically from some source
> external to
> >> HTTP or TLS) it SHOULD check the identity as described above.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Rescorla
> >> [Page 5]
> >> Internet-Draft HTTP Over TLS
> >>
> >>
> >> References
> >> [PKIX] R. Housley, W. Ford, W. Polk, D. Solo, Internet
> Public Key
> >> Infrastructure: Part I: X.509 Certificate and CRL Profile,
> >> <draft-ietf-pkix-ipki-part1-06.txt>, October 1997.
> >>
> >> [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
> >> Berners-Lee, T., "Hypertext Transfer Protocol -- HTTP/1.1"
> >> RFC 2068, January 1997.
> >>
> >> [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate
> >> Requirement Levels", RFC2119, March 1997.
> >>
> >> [TLS] Dierks, T., Allen, C., "The TLS Protocol", RFCXXXX,
> >> November 1997.
> >>
> >> Security Considerations
> >>
> >> This entire document is about security.
> >>
> >> Author's Address
> >>
> >> Eric Rescorla <ekr@terisa.com>
> >> Terisa Systems, Inc.
> >> 4984 El Camino Real
> >> Los Altos, CA 94022
> >> Phone: (650) 919-1753
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Rescorla
> >> [Page 6]
> >> Internet-Draft HTTP Over TLS
> >>
> >>
> >>
> >>
> >>
> >> Table of Contents
> >>
> >>
> >>
> >>
> >> 1. Introduction
> >> ................................................... 1
> >>
> >> 1.1. Discussion of this Draft
> >> ..................................... 1
> >>
> >> 1.2. Requirements Terminology
> >> ..................................... 2
> >>
> >> 2. HTTP Over TLS
> >> .................................................. 2
> >>
> >> 2.1. Connection Initiation
> >> ........................................ 2
> >>
> >> 2.2. Connection Closure
> >> ........................................... 2
> >>
> >> 2.2.1. Client Behavior
> >> ............................................ 3
> >>
> >> 2.2.2. Server Behavior
> >> ............................................ 3
> >>
> >> 2.3. Port Number
> >> .................................................. 4
> >>
> >> 2.4. URI Format
> >> ................................................... 4
> >>
> >> 3. Endpoint Identification
> >> ........................................ 4
> >>
> >> 3.1. Server Identity
> >> .............................................. 4
> >>
> >> RN Client Identity
> >> ................................................ 5
> >>
> >> References
> >> ........................................................ 6
> >>
> >> Security Considerations
> >> ........................................... 6
> >>
> >> Author's Address
> >> .................................................. 6
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> ---
> >> You are currently subscribed to ietf-tls as:
> >> [treese@OpenMarket.com]
> >> To unsubscribe, forward this message to
> >> leave-ietf-tls-405H@lists.consensus.com
> >>
> >
> >---
> >You are currently subscribed to ietf-tls as: [treese@OpenMarket.com]
> >To unsubscribe, forward this message to
> leave-ietf-tls-405H@lists.consensus.com
> >
>