Subject: [TLS] WG Last Call for draft-ietf-tls-psk-02.txt

From: Eric Rescorla <[email-masked]>
Date: Mon, 18 Oct 2004 14:51:00 -0700

This is a formal WG Last Call for draft-ietf-tls-psk-02.txt.
This document is intended for Proposed Standard status.

This WGLC will last two weeks.

Please send any comments to the mailing list by Nov 1, 2004.

-Ekr

P.S. Peter Gutmann, your issues have already been noted and
I will treat them as Last Call comment.

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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 19 Oct 2004 01:36:58 +0200

> Please send any comments to the mailing list by Nov 1, 2004.
Hello,

I suddenly felt anxious about it! Too few time given I think. Anyway
some comments (I may be repeating some).

-1. Introduction:
-   The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm)
-   use a PSK to authenticate a Diffie-Hellman exchange.  These
-   ciphersuites protect against dictionary attacks by passive
I don't think that here "dictionary attacks" is appropriate. PSK is 
not supposed to be a password based authentication (as also stated in section 
1.1), so dictionary attacks do not apply. Could be replaced by "brute force 
attacks", although I think that only "provide Perfect Forward Secrecy (PFS)"
would do.

-   The third set of ciphersuites (with RSA_PSK key exchange algorithm),
-   defined in Section 4, combine public key based authentication of the
-   server (using RSA and certificates) with mutual authentication using
Why do certificate authentication of the server? I can understand it for SRP
where there is no shared key but a password that may leak. For a preshared key 
I don't know how usefull is that. And also why are the certificate 
authenticated ciphersuites are restricted to RSA only? If one wants
PSK with certificates and RSA, he might also want PSK with certificates and 
DHE so he has perfect forward secrecy as well. (actually I wouldn't want 
either :)

Also the name selection does not help. TLS_DHE_PSK* ciphersuites  are not
cert. authenticated and TLS_RSA_PSK* are, so they cannot be directly 
recognised by the name (especially if in later draft TLS_DHE_PSK with 
certificates is defined). 
I'd suggest to rename RSA_PSK to RSA_CPSK or something in order to make clear
that this is a certificate authenticated ciphersuite. 

-2. PSK key exchange algorithm
-   This document does not specify the format of the PSK identity or PSK
-   identity hint; neither is specified how exactly the client uses the
-  hint (if it uses it at all).  
(here I am repeating myself --sorry:)
I believe that the above is unacceptable for a standard. Although below there 
is some recommended behaviour, I think that this will cause problems. I don't 
want to reverse engineer other implementations to see how they use this
field, in order to be compatible. 

I'm for restricting this field only to UTF-8. If implementations are supposed 
to use other encodings/string types than the recommended UTF-8 then  a type 
tag has to be added.
Otherwise there is no way to distinguish data stored in that field. 
The same comment applies about the psk_identity in the client hello.

PS. Are there now any implementations of this draft?

-- 
Nikos Mavrogiannopoulos