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