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

> >  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.
> You misunderstand. This text refers to a premature close, i.e. one
> in which the server closes the underlying transport (a 
> connection close)

Why should a TLS HTTP server close the TCP layer without
closing the TLS layer at first? (This could be if an internal
server error occurred but not for signalling end of data.)

> without signalling a close_notify. (See section 2.2 for this 
> definition). As I state, this cannot be distinguished from a 
> forged TCP FIN. Would it be clearer if the text said 
> "spurious connection
> close" instead of "spurious close"

Possibly I really don't understand that topic... If so I'm sorry.
The draft says that [ client implementations MUST treat any premature 
closes as errors ] *EXCEPT* the two cases which deserve special note.

1. A TLS HTTP server SHOULD not signal the end of data through a 
   premature close. That's only true for plain HTTP servers. 

2. Even the server has miscomputed the Content-Length it knows 
   when all the data has been sent. (Otherwise it is in 
   a very strange state). It can close the TLS connection 
   properly too.

> >  [ 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.
> The general behavior is that you should close the TLS layer
> correctly (at the very least send a close_notify) in the
> same circumstances in which you would close the TCP layer
> correctly. (I.e. send a FIN). The point is to provide protection
> for the message traffic, not to provide additional signalling.
> 
> So, the answer for Q 2 is clearly 2.2. 

I agree. (Unfortunately 2.2 does not exist. I made a typo =(.

> I believe that servers
> normally simply close the connection (with a FIN) if an error
> occurs, so the answer for Q 1 is 1.2 as well.

Here we should have some comments from Apache group, Microsoft
or Netscape. I can't answer this question.

Regards Rene