Draft: Review of draft-ietf-tls-psk-08.txt Review: Lakshminath Dondeti Date: 27 april 2005 I'd call tls-psk-08 ready (a bit reluctantly, but the I-D should move forward now). -------- Original Message -------- Subject: RE: Review of draft-ietf-tls-psk-07.txt Date: Mon, 25 Apr 2005 16:51:33 -0400 From: Russ Housley To: ,, CC: , References: I am fine with the proposed resolution to these comments. Russ At 12:41 PM 4/6/2005, Pasi.Eronen@nokia.com wrote: > Thanks for your review, Lakshminath! > > Russ, could you check that you're happy with the suggested > handling of these comments? (If so, I can submit a revised > I-D later this week.) > > > I am reviewing this I-D as part of the Gen-Art IETF LC review > > process. > > > > > > > Please include a table of contents. > > Ok, will be added. > > > > 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. > > The motivation text is before the three ciphersuite sets (PSK, > DHE_PSK, RSA_PSK) have been introduced, and the text a couple > of paragraphs later does describe that only the PSK variants > are free of public-key operations. > > But perhaps we should clarify it slightly by changing > > o First, TLS may be used in performance-constrained > environments where the CPU power needed for public key > operations is not available. > > to this? > > o First, using pre-shared keys can, depending on the > ciphersuite, avoid the need for public key operations. > This is useful if TLS is used in performance-constrained > environments with limited CPU power. > > > (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). > > I agree that performance issues change quickly. Most devices > get faster, but decreasing prices also enable new low-cost > low-performance devices that were not economical earlier. > > But I'm not sure how useful it would be to include this kind of > discussion in this document. The text would get old pretty fast, > and a meaningful comparison of the performance differences of > various TLS ciphersuites in different kinds of devices would > easily take several pages. > > > 2. In the last paragraph of Section 1, delete with in "with > > RSA_PSK key exchange algorithm" replace "mutual" with "client" > > Technically, "mutual" is correct (if not very elegant English): > the server also proves to the client that it knows the PSK. > > (It certainly would have been possible to design the RSA_PSK > ciphersuites so that the PSK is used only for client-to-server > authentication, but that was not done.) > > > 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. > > > 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. > > Since the applicability statement is quite short (three > paragraphs), I don't think splitting it to two subsections > would be helpful. Besides, discussing the other alternatives > (e.g. self-signed certs and SRP) is one good way to describe > when PSKs are and are not the best choice. > > (But if you have concrete suggestions on how this section > should be rephrased, they're certainly welcome.) > > > 4. Replace all occurrences of "an uint16" with "a uint16" > > OK, will be done. > > > 5. On "See [8] for a more detailed rationale.": Considering > > [8] is an email, please summarize the rationale in the I-D > > for completeness. > > Well, the rationale is IMHO not very interesting, and the choice > was, to some degree, arbitrary: other alternatives would have > been OK as well. > > How about changing note 2 from > > Note 2: Using zeroes for "other_secret" effectively means > that only the HMAC-SHA1 part (but not the HMAC-MD5 part) of > the TLS PRF is used when constructing the master secret. > See [8] for a more detailed rationale. > > to this? > > Note 2: Using zeroes for "other_secret" effectively means > that only the HMAC-SHA1 part (but not the HMAC-MD5 part) of > the TLS PRF is used when constructing the master secret. > This was considered more elegant from an analytical viewpoint > than, for instance, using the same key for both the HMAC-MD5 > and HMAC-SHA1 parts. See [8] for a more detailed rationale. > > > 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 > > It seems the wording of these paragraphs has been fine-tuned in > almost every revision of the document :-) > > The document already describes the premaster secret construction > in two different ways, as plain English (concatenate this and > that), and by using the "general structure" shown in TLS > presentation language ("struct { .. }") in Section 2. > > I think a third way to describe the same thing would be a bit > redundant... So unless you think the current descriptions are > ambiguous (and would lead to interoperability problems), I'd > suggest keeping them as they are. > > > 8. In Section 7.2, it might be worthwhile to include a > > passphrase to PSK generation function for easy reference. > > Section 7.2 recommends providing functionality for generating a > random PSK, but if the PSK is entered as an ASCII string > (Section 5.4 requires management interface support for it), > it's used as entered. > > Or in other words, it's not run through anything like PKCS#5 > PBKDF2 before being used. (If it was, TLS-PSK would also have to > negotiate (or specify) the various parameters (like iteration > count) needed by PBKDF2 to get any interoperability. There was > at some point also discussion about using PKCS#5 PBKDF2 for all > keys; Hugo's mail in [8] also has parts related to this.) > > Best regards, > Pasi