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

Rene Eberhard <[email protected]> Wed, 13 Oct 1999 09:32:56 -0400
Newsgroups gmane.ietf.apps-tls
Message-ID <C7657405A7D6D21185950008C724736504A8EA@schzmxs1.europe.entrust.com>
Hi

1. Typo on line 85: 'sentas' should be 'sent as'

2. 
 > 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.
 We've already had a discussion about some of the topics below.
 If the server is implemented correctly it closes gracefully.
 
3. 
 > 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.
 If the server is implemented correctly it closes gracefully even the
 the header contains the wrong length.
 
4.
 > When encountering a premature close, a client SHOULD treat as com-
 > pleted all requests for which it has received as much data as speci-
 > fied in the Content-Length header.
 11 lines above you describe the case where no Content-Length header
 is sent. What is the recommendation in that case?

5.
> In general, HTTP/TLS requests are generated by dereferencing a URI.
> As a consequence, the hostname for the server is known to the client.
What is the recommendation if the server is only reachable through
an IP address?

6.
 > In special cases, it may be appropriate for
 > the client to simply ignore the server's identity, but it must be
 > understood that this leaves the connection open to active attack.
I'd remove this sentence.


...nevertheless great work.

Regards Rene