Re: I-D ACTION:draft-ietf-tls-https-03.txt

Folks,

a few comments, most of which are kind of editorial.

>                                                           E. Rescorla
> INTERNET-DRAFT                                              RTFM, Inc.
> <draft-ietf-tls-https-03.txt>        September 1999 (Expires March-00)
>
>                              HTTP Over TLS
>
> Status of this Memo
>
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026.  Internet-Drafts are working

RFC2026 is missing in the References section.

>    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.
>
> [...]
>
> 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 appro-
>    priate port and then send the TLS ClientHello to begin the TLS hand-
>    shake. When the TLS handshake has finished. The client may then ini-
>    tiate the first HTTP request.  All HTTP data MUST be sentas TLS

I guess this should read: "When the TLS handshake has finished the client
MAY initiate the first HTTP request." Correct?

Futhermore, the term "sentas" is unknown to me.  :)

>    "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
>
> Rescorla                                                         [Page 2]
> Internet-Draft                HTTP Over TLS
>
>    boundaries, it is necessary to examine the HTTP data itself (specifi-
>    cally the Content-Length header) to determine whether the truncation
>    occurred inside a message or between messages.

I think this last sentence is way too unspecific. Should the TLS implementation
examine the HTTP header or the HTTP implementation or the user? And what
does "examine" mean? What happens after the examination?

We need to be more explicit here.

> [...]
>
> 2.2.2.  Server Behavior
>
>    RFC2068 permits an HTTP client to close the connection at any time,

RFC2068 is missing in the References section.

>    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.

...is reached? Shouldn't we include a short example of how the client is
able to determine the end of data?

>    Servers SHOULD be willing to resume TLS sessions closed in this fash-
>    ion.
>
>    Implementation note: In HTTP implementations which do not use persis-
>    tent connections, the server ordinarily expects to be able to signal
>    end of data by closing the connection. When Content-Length is used,
>    however, the client may have already sent the closure alert and
>
> Rescorla                                                         [Page 3]
> Internet-Draft                HTTP Over TLS
>
>    dropped the connection.
>
>    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

Insert the word "protocol" after the word transport.

>    stream.
>
> [...]
>
> References
>    [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
>       Public Key Infrastructure: Part I: X.509 Certificate and CRL
>       Profile", RFC 2459, January 1999.
>
>    [RFC-2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,

This should read "RFC2616" (no "-").

>       Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
>       Transfer Protocol, HTTP/1.1" RFC 2616, June 1999.
>
>    [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate
>       Requirement Levels", RFC2119, March 1997.
>
>    [TLS] Dierks, T., Allen, C., "The TLS Protocol", RFC2246, January 1999.

References to RFC2026 and RFC2068 are missing.

Comments?

Cheers,

        Stefan.

______________________________________________________________________________
Stefan Kelm            PGP key: "finger [email protected]" or via key server
DFN-PCA                                                      <[email protected]>
Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)                   Tel: +49 40 428 83-2262 / Fax: -2241