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

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.

>>    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)?  The language of properly formatted HTTP requests
is prefix-free, so the server never has to worry even when the client
aborts a connection without cleanly closing it; so why worry about
incomplete closure by the client, i.e. the client sending a
closure_alert without waiting for the one from the server?
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.


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:

   [...]

>> References

>>   [RFC-2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,

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

Even better, "RFC 2616".

> References to RFC2026 and RFC2068 are missing.

None is needed for RFC 2026 (no Internet Draft I know of references
RFC 2026), and 2068 was just mentioned by accident, so again no
reference is needed.


Bodo M"oller
<[email protected]>