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

[email protected] (Bodo Moeller) writes:

> Stefan Kelm <[email protected]>:
> 
> >> <draft-ietf-tls-https-03.txt>        September 1999 (Expires March-00)
> 
> >> 2.2.2.  Server Behavior
> >>
> >>    RFC2068 permits an HTTP client to close the connection at any time,
> 
> > RFC2068 is missing in the References section.
> 
> Because it's been obsoleted by RFC 2616.  draft-ietf-tls-https-02.txt
> always referenced 2068, this has now been changed; some occurences of
> that number obviously have been missed.
Right. This is a bug. We'll fix it as last call comments.


> >>    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?
> 
> I'm not even sure if that sentence makes sense -- the client often can
> see where the server data ends, sure, but what does that have to do
> with the client's closing the connection to the server (i.e. the
> reverse direction)?
Because some clients (notably Netscape) have been known to close the
connection once they've received a complete response, without
performing a connection close.

> The server won't even notice  if the client ignores its closure_alert,
> except when the client RSTs the connection; and even then the
> difference between RST and proper FIN does not matter to the server
> because it is not cryptographically secured.
I agree. That's what this text means. The issue is that 
the server should not throw an error when he tries to write
to the client and the write() returns an error. The server
should accept this behavior silently.

> There's been some discussion on section 2.2.1 (Client Behavior),
> which possibly also needs clarification:
> 
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 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.
> 
> [...]
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> 
> Here it was not clear to everyone what that "special note" really is
> to say.  A rough proposal for how to change the text:
> 
> 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.  While in some cases
>    the HTTP protocol allows the client to find out whether truncation
>    took place so that, if it received the complete reply, it may
>    tolerate such errors following the principle to "[be] strict when
>    sending and tolerant when receiving" [RFC 1958], often truncation
>    does not show in the HTTP protocol data; two cases in particular
>    deserve special note:
> 
>    [...]
I'll make this change unless there are any objections.

-Ekr


-- 
[Eric Rescorla                                   [email protected]]
          PureTLS - free SSLv3/TLS software for Java
                http://www.rtfm.com/puretls/