Document: draft-ietf-tls-psk-07.txt
Review: Lakshminath Dondeti 
Date: 31 mars 2005 


Summary
--------------
This draft is basically ready for publication, but has nits that
should be fixed before publication.

idnits output
------------------

-bash-2.05b$ ./idnits --verbose draft-ietf-tls-psk-07.txt
idnits 1.61

draft-ietf-tls-psk-07.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html :

  * The document seems to lack an Authors' Addresses Section.
    Checking conformance with RFC 3978/3979 boilerplate...
    the boilerplate looks good.

You might ignore this, as the script seems to have missed the Authors'
and Contributors' Addresses section in the I-D.

  * The document is more than 15 pages and seems to lack a Table of
    Contents.

Please include a table of contents.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :

    Nothing found here (but these checks does not cover all of
    1id-guidelines.txt yet).

  Miscellaneous warnings:

    None.

Review
----------

I followed the WGLC discussion on this draft, and had a chance to
review Pasi's summary of the issues and resolutions.  This draft has
received the due review in the WG.  However, I do have some additional
editorial comments to further improve the I-D.

1. The motivation might need to be revised.  The first reason seems to
be at odds with the RSA_PSK ciphersuites and DKE_PSK ciphersuites.

The second reason makes sense in that the proposed protocol provides a
solution for environments where PSKs are already in place.

(On the issue of small devices and performance constraints, with
Moore's law, performance constraints of today might be invalid in a
few years.  Of course, with Moore's law the requisite key lengths
etc., also increase.  Then comes the question of how PSKs compare with
public key operations with shorter keys.  It might be worthwhile for
this I-D, and the eventual RFC to include such a discussion).

2. In the last paragraph of Section 1, 
   delete with in "with RSA_PSK key exchange algorithm"
   replace "mutual" with "client"

3. The Applicability Statement needs work.    Please rewrite the
applicability statement to clearly state the intended use alone.  The
alternatives, self-signed certs and SRP ciphersuites can go elsewhere,
perhaps in the Security Considerations section.

4. Replace all occurrences of "an uint16" with "a uint16"

5. On "See [8] for a more detailed rationale.": Considering [8] is an
email, please summarize the rationale in the I-D for completeness.

6. In Page 6, please add the following to the second to last paragraph.

PreMaster Secret = length-of-Z-in-octets || Z || length-of-PSK-in-octets || PSK

where the "length" fields are of type unit16

or something like that.

7. In Section 4, the paragraph starting with "The
EncryptedPreMasterSecret ..." needs some work.

Perhaps including a line similar to the one suggested above might help.

PreMasterSecret = length-of-EncryptedPreMasterSecret-in-octets ||
EncryptedPreMasterSecrtet || length-of-PSK ||  PSK

8.  In Section 7.2, it might be worthwhile to include a passphrase to
PSK generation function for easy reference.

9.  As noted earlier, please suggest alternatives to PSKs in Section
7.2 or in a separate subsection in Section 7.

That section should say something along the lines of: PSKs should only
be used after other alternatives such as xx (self-signed certs?) and
yy (TLS-SRP?) have been ruled out either due to performance
constraints or deployment constraints etc.