Document: draft-ietf-tls-psk-null-02.txt Reviewer: Spencer Dawkins Review Date: 2006-10-09 IETF LC Date: 2006-10-19 Summary: This document is almost ready to publish as a Proposed Standard. Although I do have some comments, all of them would fit in an RFC Editor note. Please note that I also flagged some editorial things as "Spencer (editorial):" - these are not part of the Gen-ART review but are included for the convenience of other editors downstream. Comments: The last call also asked for guidance on PS or Informational. The document seems reasonable to PS, especially since it extends a PS RFC, but Do The Right Thing. Abstract This document specifies authentication-only cipher suites for the Pre-Shared Key based Transport Layer Security (TLS) protocol to support null encryption. These cipher suites are useful for countries and places with cryptography-related restrictions. Spencer: what the Abstract is saying is explained clearly in the Introduction, but I had to read the Introduction to understand the Abstract. Suggest a minor edit, as follows: This document specifies null-encryption cipher suites for the Pre-Shared Key based Transport Layer Security (TLS) protocol to support authentication without encryption. These cipher suites are useful for countries and places with cryptography-related restrictions. Spencer: I'm also wondering if there are applicable environments that aren't bounded by countries or places, but would be guided by the authors and the working group here (I left my security pixie dust in my other backpack). Conventions used in this document Spencer: I didn't see any 2119 keywords - are there any I missed? If not, the 2119 Conventions text and reference could go away. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1. Introduction The RFC for Pre-Shared Key based TLS [TLS-PSK] specifies cipher suites for supporting TLS using pre-shared symmetric keys. However all the cipher suites defined in [TLS-PSK] require encryption. There is a need for cipher suites that support no encryption. This is required for implementations to meet import restrictions in some countries. Even though no encryption is used, these cipher suites Spencer (editorial): whatever the working group thinks about my previous "countries or places" comment, it would be nice if the same words appeared together with "countries" here. support authentication of the client and server to each other, and message integrity. This document augments [TLS-PSK] by adding three more cipher suites (PSK, DHE_PSK, RSA_PSK) with authentication and integrity only - no encryption. 2. Cipher Usage The new cipher suites proposed here is very similar to cipher suites defined in [TLS-PSK], except that they define null encryption. Spencer: It might be nice to explicitly say something like, "... define null encryption cipher suites for each of the three key exchange algorithms used in [TLS-PSK]". It was not immediately obvious to me why THREE null cipher suites were defined to do ONE thing - encryptionless authentication. The cipher suites defined here use the following options for key exchange and hash part of the protocol: CipherSuite Key Exchange Cipher Hash TLS_PSK_WITH_NULL_SHA PSK NULL SHA TLS_DHE_PSK_WITH_NULL_SHA DHE_PSK NULL SHA TLS_RSA_PSK_WITH_NULL_SHA RSA_PSK NULL SHA For the meaning of the terms PSK please refer to section 1 in [TLS- PSK]. For the meaning of the terms DHE and RSA please refer to section 7.4.2 in [TLS]. Spencer (editorial): PSK has been previously spelled out (sort of) in the Introduction, but DHE, RSA, and SHA have not. It might be nice to spell them out on first use (although you never actually NEED for the reader to know what they are in your document, because you only mention them to point the reader to [TLS]). >From the nit-checker... *I* can't tell the difference, but this was flagged by the tool, so... idnits 1.111 tmp/draft-ietf-tls-psk-null-02.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3979 Section 5, para 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 3979 Section 5 paragraph 1 text: "The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79."