Hi, Uri and Purushottam,
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-tls-psk-null-02.txt
Reviewer: Spencer Dawkins
Review Date: 2006-10-09
IETF LC Date: 2006-10-19
IESG Telechat date: (not known)
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."
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
