Re: I-D ACTION:draft-ietf-tls-https-03.txt
EKR <[email protected]> 13 Oct 1999 07:29:35 -0700
| Newsgroups | gmane.ietf.apps-tls |
|---|---|
| Message-ID | <[email protected]> |
Rene Eberhard <[email protected]> writes: > Hi > > 1. Typo on line 85: 'sentas' should be 'sent as' Agred. I'll fix this. > 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. Agreed. See my responses to your previous message. > 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. Agreed. > 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? Ah. You're right. This is the one case where the client should not treat this as an error. That's what the text is supposed to mean, but it doesn't say so clearly. > 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? In that case, the certificate should contain the IP address. I'll add some appropriate text. Unless there are any objections. >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. This text resulted from some comments by Keith Moore about there being such environments. I want to make clear the security consequences of such a decision. Thus, I'm unwilling to remove this text. Thanks for your comments Cheers, -Ekr -- [Eric Rescorla [email protected]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/