Thanks for putting this on the TLS agenda, it certainly needs some
further clarification.
I will be there, if you need any further clarification from the IPP
group.
Eric's draft did not make it time for the Chicago cut-off date, but was
distributed on the TLS DL.
I expect that it will show up on the IETF I-D list after Chicago.
Carl-Uno
> -----Original Message-----
> From: Rodney Thayer [mailto:Rodney@unitran.com]
> Sent: Saturday, August 22, 1998 2:36 PM
> To: IETF Transport Layer Security WG
> Cc: ipp@pwg.org
> Subject: IPP> RE: HTTP/TLS draft
>
>
> I've put this on the agenda for the TLS meeting. I myself
> wasn't aware
> of this draft (did they announce it on the TLS list?) and I see it
> doesn't reference Eric's draft, which I know Keith was aware
> of, so I'm
> feeling confused...
>
> -----Original Message-----
> From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com]
> Sent: Saturday, August 22, 1998 12:13 PM
> To: IETF Transport Layer Security WG
> Cc: ipp@pwg.org
> Subject: RE: HTTP/TLS draft
>
>
> I have a follow-up question on the previous post.
>
> Is the intent of the "HTTP Over TLS" draft to have it published as a
> standards track document or only as an informational document?
>
> The expectation from the IPP group was that it would go on
> the standards
> track so that we could reference it, otherwise we cannot. The HTTP and
> WebDAV groups would be in same boat I expect.
>
> What is the general rule for TLS profile documents? Are they
> expected to
> be standards track level documents or what?
> Maybe this is stated somewhere in the TLS documents, but if
> so I missed
> it.
>
> Carl-Uno
>
> > -----Original Message-----
> > From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com]
> > Sent: Saturday, August 22, 1998 5:12 AM
> > To: IETF Transport Layer Security WG
> > Cc: ipp@pwg.org
> > Subject: RE: HTTP/TLS draft
> >
> >
> > 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:
> > > [rodney@unitran.com]
> > > To unsubscribe, forward this message to
> > > leave-ietf-tls-812E@lists.consensus.com
> > >
> >
> > ---
> > You are currently subscribed to ietf-tls as:
> > [rodney@unitran.com]
> > To unsubscribe, forward this message to
> > leave-ietf-tls-812E@lists.consensus.com
> >
>
> ---
> You are currently subscribed to ietf-tls as: [rodney@unitran.com]
> To unsubscribe, forward this message to
> leave-ietf-tls-812E@lists.consensus.com
>