Re: WG Last Call: HTTP over TLS (draft-ietf-tls-https-02.txt)

Rene Eberhard <[email protected]>:

> Below a few comments to draft-ietf-tls-https-02.txt.

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

>      It is unclear whether the "Connection: close" as defined in RFC2068 or
>      a connection termination is considered.

You could not receive a "Connection: close" *after* the closure alert.
Obviously this is about transport protocol closures -- FIN packets in
the case of TCP.
 
>      The question is whether a 'close' could be received. In my
>      opinion a HTTP client/server can detect a close
>      but not receive.

That's a matter of taste; I think I would have chosen words different
from those the draft, but the wording in the draft makes sense too.
Of course if the text in the draft is easily misunderstood, then it
may be worthwile to look for an alternative wording.

> 2.2.1. Client Behavior
>   1. > Because HTTP uses connection closure to signal end of server data,...
>      'HTTP' refers to RFC2068. The default behavior of HTTP/1.1 is keep alive. 
>      Otherwise a 'Connection: Close' header must be added.

HTTP/1.1 is now RFC 2616 -- the "References" section in 
draft-ietf-tls-https-02.txt is out of date.
Anyway, note that HTTP/1.1 allows using connection closure to indicate
the end of the message body (obviously you don't keep a persistent
connection then):

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
4.4 Message Length

>>> RFC 2068 version:
   When a message-body is included with a message, the length of that
   body is determined by one of the following (in order of precedence):
<<<
>>> RFC 2616 version:
   The transfer-length of a message is the length of the message-body as
   it appears in the message; that is, after any transfer-codings have
   been applied. When a message-body is included with a message, the
   transfer-length of that body is determined by one of the following
   (in order of precedence):
<<<

   [...]

   5. By the server closing the connection. (Closing the connection
     cannot be used to indicate the end of a request body, since that
     would leave no possibility for the server to send back a response.)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

(The final sentence is not true for HTTP on top of TCP, but when the
transport includes HTTPS, it is.)

>   2. > client implementations MUST treat any premature closes as errors and
>      > the data received as potentially truncated.
>      That means that a HTTP client behaves different using TCP or TLS. 
>      That's contrariety to section '2. HTTP Over TLS'.
>      In general a HTTP client using TCP can not detect a premature close 
>      without having the content length info.

TLS closure alerts provide authentication for the server's closing the
connection.  For plain HTTP, the client can differentiate between a
proper close (FIN) and some protocol error (e.g. a RST, or a lost
connection).  When TLS is employed, you don't want attackers to be
able to prematurely close the connection (i.e. send TCP FINs) without
evoking suspicion.  That's what TLS closure alerts are for.
(Stupidly, Microsoft Internet Explorer does it the other way around --
closure alerts are reported as protocol errors, while just closing the
TCP connection works.  Netscape just ignores closure alerts, which can
lead to deadlocks if the server waits for the client's TLS closure
alerts without sending a TCP FIN first.)

>   3. > Clients MUST send a closure alert before closing the connection.

>      It's up to the TLS layer whether it sends a close_notify message 
>      or not. For the HTTP client the underlying layer should be transparent and
>      thus a closure call to that layer looks equal either using TCP or TLS. 
>      Of course a TLS layer should send the close_notify message before closing 
>      its underlying layer (TCP). But this can not be forced
>      especially for HTTP clients.

So what?  For purposes of this draft, the TLS layer is part of the
client.  The above sentence from the draft is redundant given the TLS
specification in RFC 2246, but that's apparently intended: The draft
states what the TLS rules for closure alerts mean for the HTTPS
protocol.


> 2.4. URI Format
>   In the real world this example always fails. Why don't we 
>   use something like https://abc.com/~smith/home.html or
>   https://abc.com:7443/~smith/home.html?

That example (https://abc.com:80/~smith/home.html) indeed is strange.


> 3.2. Client Identity
>   The server identity is well defined. We have to consider that, in general,
>   the purpose of identifying a server is different than identifying a client.
>   Client identifying is used to identify a person while server identifying
>   is used to identify a machine. Thus the matching rules as described in 3.1
> 
>   are not applicable.

The draft does not claim that they are.  Section 3.1 is titled "Server
Identity", section 3.2 is titled "Client Identity".  (Also I disagree
that client certificates are about persons.  They can be, but this
is not at all mandatory.)