March 5, 2002
This document also available in PDF.
I wish to thank NIST for the opportunity to review and to comment on the document and for its effort to create the document.
Several issues can be raised generally, as they apply throughout the document. With regard to terminology, I have two remarks.
Additionally, there seems to be some missing discussion of URI sensitivity. Specifically, I strongly recommend that URIs never contain any datum that could be considered non-public, as URIs are recorded in numerous locations: web client logs, proxy caching server logs, and in some cases, third-party HTTP referrer logs. In no case should a URI contain data that would allow someone to access something he otherwise should not. For example, simply ``hiding'' a host by not publishing its existence is ineffective. Another example would be the use of user names and passwords in URIs, which is part of the specification, but bad security practice.
Section 3 seems to jump directly into specifics, enumerating the needs for identification of the components, without providing or citing any basis for the reasons why. The Saltzer-Schroeder design principles  are well worth considering in this context, not just from the perspective of implementing systems, e.g., as programmers, but for configuration and operation of systems. Perhaps the end of section 3.1 could include a review and brief explanation of each of these, particularly as they relate to web services. Detailed discussion of these design principles as they apply to web services can be found in my book, Developing Trust: Online Privacy and Security . The document encourages many of these practices, but there is little reason behind the practice. For example, passwords of eight characters or more are recommended, but there is no discussion of work factor, the real issue at hand, which will allow administrators to decide appropriate password length to fit their own policies.
The principles might be thus summarized:
The remainder of this document deals with comments I have on particular sections of the document.
In the context of disabling unneeded services, it's also noteworthy that web servers generally have no need to make client connections to the Internet. Packet-filtering routers can be used to enforce that policy. If administrators enforced this policy, Code Red and its progeny would not have become the problems that they were.
Section 4.2's discussion of web robots is very helpful. One explicit warning that is missing, however, is that the Robot Exclusion Standard is not followed by ill-intentioned robots like Email Siphon and Cherry Picker. Further, some ``email address harvesting'' bots will use the robots.txt content to find areas of the site to crawl. Thus, the advice is sound, but it should be pointed out that the spam bots will not follow the directives.
Section 5 falls into a dangerous trap, the identification of data sensitivity by how ``personal'' it is. This definition does not have the support of information science and sound security policy, but rather that of marketers attempting to avoid public outcry and litigation over their self-serving data handling practices. As an example, the document's definition of what constitutes personal information lacks medical data, yet many HIV-positive web users would find that data intensely personal. The document does include financial data, yet many public employees' salaries are a matter of public record. IP address is cited as ``personal information'' yet it is necessary for the web server to receive the request for information, and DNS PTR records might even advertise the name of the host. The attempt to classify broadly what is and isn't ``personal'' and therefore what may and may not be handled without consent is wrong-headed. Instead, it is better to follow the Salter-Schroeder advice of fail-safe defaults, not gathering anything except by what is explicitly allowed. It should never be acceptable to collect any data not needed for the transaction or to use it for any other purpose than the servicing of the request by default.
Section 5's discussion of cookies also misses an important point, that sensitive data can be correlated and collected with any type of cookie. The only difference is that in session cookies, the lifetime of the cookie is generally shorter, thus increasing the work factor needed to correlate data from session to session. However, the issue with cookies is not one of data sensitivity, but one of nymity. Cookies are most often used to give users unique identifiers, which are pseudonyms that last for the duration of the cookie. Pseudonymity is very different from anonymity, and the risks presented pseudonymous users are different from the risks presented properly anonymous users .
It should also be noted that cookies, even when marked ``secure'', should not be used to transfer data that could be used directly by an attacker. In some environments, for example, persistent cookies would be stored on unencrypted network filesystems, such that a cookie received by the browser over a secure channel might be transmitted over the local network in the clear. This could have significant ramifications in the scenario of an attacker that has access to the same network as a legitimate user .
Discussion of TLS weaknesses in section 6.5.2 make it sound as though the man-in-the-middle attack is an unsolved problem or that manual verification of the browser's ``Location'' URI is sufficient protection. In reality, the TLS handshake will pass certificates, and the browser software will check the certificate's signatures. If a trusted signing authority has signed the certificate, the certificate will be accepted. However, the problem present here is that it places all trust in the signing authorities, many of whom the users have not heard, and some of which have been compromised. The weaknesses in TLS are not weaknesses in TLS per se, but are weaknesses inherent in any system requiring a centrally-administered public key infrastructure (PKI).
Table 6.1 shows 3DES as having a 168-bit key. It isn't clear whether this is an oversight (asserting 3DES always has a 168-bit key) or a specification (of a three-key mode of ANSI X9.52).
RFC1945 is cited in section 6.5.5, but that's an old version of the HTTP specification. The present specification is RFC2616, with updates for TLS coming from RFC2817.
Security testing discussed in Section 8.4 lacks an important warning: testing the security of a production system can have unintended consequences if the tester checks for weakness by attempting to exploit it. Security vulnerabilities are often the result of some kind of system failure, which can introduce additional side-effects, including instability and data corruption.
Recommended practice for handling of content and configuration is generally sound, but it might be worth adding that the use of a revision control system can greatly increase the flexibility and stability of managing content, particularly where many persons are involved in development and operation.
This document was generated using the LaTeX2HTML translator Version 99.2beta8 (1.46)
Copyright © 1993, 1994, 1995, 1996,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 0 -no_navigation -show_section_numbers nist-w3sec
The translation was initiated by Matt Curtin on 2002-03-05