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

Hi

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

Of course you are right. But why use synonyms when you can
use "closure alert" or "close_notify"?

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

I fully support the definition of the "close_notify" used in HTTP 
over TLS but I'm unhappy with the current state. Perhaps I misunderstood
the topic.

 [ 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.]
 
 Of course it can. In this case the server can properly close the TLS 
 layer. TLS sends the "close_notify" and closes the underlying transport
 layer (TCP). This ends in a "incomplete close" which is okay.
 
 [ 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. ]

Now its getting interesting. How should a server behave when
1. an internal error occurred?
   1.1 Close the TCP layer (FIN, RST) which ends up in a
       "premature close". In this case the client
       can detect that something unexpected had happened.

   1.2 Close the TLS layer which closes the TCP layer. This
       ends up in a "incomplete close". In this case the client
       can only detect an unexpected error on the server
       side if a content length info has been sent.
         
2. the response completed successfully?
   2.1 Close the TCP layer (FIN, RST) which ends up in a
       "premature close". I see no reason why a server
       should close the TCP layer without closing
       the TLS layer before.
       
   1.2 Close the TLS layer which closes the TCP layer. This
       ends up in a "incomplete close". This is the correct 
       behavior.

Of course we can combine the "close_notify" message with 
any combination of (FIN | RST) but this would not be 
very clever =)

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

In the most cases they are. I've read through section 3.2 more 
carefully and it's okay as is.

Regards Rene