Subject: [Gen-art] Gen-ART Review of draft-ietf-tls-psk-null-02.txt

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 9 Oct 2006 16:10:57 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art