Subject: [TLS] RE: Review of draft-ietf-tls-psk-07.txt

From: [email-masked]
Date: Wed, 6 Apr 2005 19:41:01 +0300

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.
>
<snip>
>
> Please include a table of contents.

Ok, will be added.

<snip>
> 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.
<snip>
> 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

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 14 Apr 2005 14:23:12 -0700

Hi Pasi and all,

Apologies for the delay in my reply to this.  Please see inline for some 
additional thoughts.

>should be rephrased, they're certainly welcome.)
Applicability statement:

+++++++++++++++
The ciphersuites defined in this document offer weak security properties 
and thus intended for constrained scenarios where stronger ciphersuites 
cannot be used due to deployment issues and performance constraints. 

If performance is not an issue, self-signed certificates with public key 
fingerprints might be more appropriate than TLS-PSK ciphersuites.  The 
configuration complexity between self-signed certs with public key 
fingerprints is comparable, if not slightly more efficient, to shared 
secret configuration.  Another alternative is to use Secure Remote 
Password (SRP) ciphersuites for shared secret authentication [4].  SRP 
was designed to be used with passwords, but incorporates protection 
against dictionary attacks, i.e., more secure compared to TLS-PSK 
ciphersuites.

Self-signed certs based ciphersuites and SRP based ciphersuites require 
computationally expensive operations compared to TLS-PSK, and thus in 
computationally and battery power limited devices, TLS-PSK offers 
protection better than no security at all.  Similarly, there are 
application scenarios, where a shared secret is already established 
between two parties, where at least one of them has computational 
limitations.  Use of TLS-PSK ciphersuites is appropriate in such cases.

Finally, the general guidance is for two communicating parties to rule 
out other other TLS ciphersuites before using TLS-PSK suites, and with 
the understanding that PSK based ciphersuites are vulnerable to 
dictionary attacks, and generally weak (i.e., a moderately motivated 
adversary has a good chance of impersonating one or both parties and 
read TLS protected traffic.
+++++++++++++++++

Here is my first attempt at this (and no I don't want to spend cycles on 
revisions :-)).  Please feel free to use portions of it or none at all. 

> snip>
<snip>

That sounds ok.  My main concern is that providing a reference to a 
mailing list posting probably might not be of help to a reader some 2 
years from now.  I think that this text should stand along, and any 
credits to Hugo should just go into the Acknowledgments section 
(References should be limited to some type of publication that is 
somewhat easily retrievable in the future.  The RFC-Editor might 
complain about this).

>keys; Hugo's mail in [8] also has parts related to this.)
It might be worthwhile to have a separate small informational RFC on 
this.  Russ might find a taker :-).

best regards,
Lakshminath