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

From: [email-masked]
Date: Tue, 19 Oct 2004 17:22:17 +0300

Nikos Mavrogiannopoulos writes:
>
> Hello,
> 
> I suddenly felt anxious about it! Too few time given I think. 
> Anyway some comments (I may be repeating some).

Thanks for your comments, Nikos!

> -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 text simply acknowledges the fact that, in reality, PSKs 
may sometimes be selected by humans, and PSKs selected by 
humans tend to contain less unpredictability than purely 
random strings of the same length.

(This is, of course, no different from many other protocols
that can use shared secrets, e.g. IKE.)

"Dictionary attack" is IMHO a reasonably common and well-
understood word for that... though perhaps something like

  "...against brute force attacks by passive eavesdroppers 
  (but not active attackers) that exploit the possible lack of
  unpredictability in the PSK (e.g., the PSK is relatively
  short, or was chosen by a human and thus may contain less
  unpredictability than its length would imply), and ..."

might be technically more accurate (but probably less
understandable :-)?

> -   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 :)

I'm not totally convinced about the usefulness of the RSA_PSK
ciphersuites myself (but certainly if you don't want to use
them, you don't have to implement them :-). Any opinions
from other WG members?

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

I think the naming is reasonably consistent with other TLS
ciphersuites: "RSA" tells that certificates are used, and 
"DHE" tells that whatever follows the "DHE" part is used 
to authenticate the ephemeral DH parameters.

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

Note that there are many types of identifiers that are not
naturally composed of Unicode characters (e.g., IPv4/v6 
addresses, IEEE 802 MAC addresses, X.500 Distinguished Names, 
even DNS names). All of those can, of course, be converted to 
character strings (e.g., instead of 32-bit IPv4 address, use the 
dotted decimal ASCII string) and then UTF-8 encoded back to bytes.

In many cases, that might be a good idea even if we did
not mandate it; that's why it already says "RECOMMENDED". 
But perhaps we should change this to MUST? Any other comments 
from the WG about this? 

> PS. Are there now any implementations of this draft?

No, not to my knowledge.

Best regards,
Pasi

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

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 20 Oct 2004 15:19:23 +1300

[email-masked] writes:

>I'm not totally convinced about the usefulness of the RSA_PSK ciphersuites
>myself (but certainly if you don't want to use them, you don't have to
>implement them :-). Any opinions from other WG members?

I think they're quite useful, every server already does RSA with certs (even
if it's just a self-signed one), so I'd regard this is the second-most useful
suite after the basic PSK suites.

>>PS. Are there now any implementations of this draft?

There can't be any implementations because the suite values aren't defined.
Providing values to use would probably help increase the number of
implementations (see my earlier message on this).

Peter.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 20 Oct 2004 15:52:54 +0200

> them, you don't have to implement them :-). Any opinions
Certainly but my point also is, if certificate authenticated RSA ciphersuites
are added, then why the DHE_RSA/DHE_DSS are not added as well? A server 
with a DSS only certificate can only use DHE_DSS, so is not entitled to use 
certificate authenticated PSK. 

> to authenticate the ephemeral DH parameters.
Yes you're right. I got confused here.

> even DNS names). 
Maybe tagging it would help then. So clients and servers can use the
tags to distinguish data in that field. Otherwise there is no way to support 
all of these schemes, and we end up with clients and servers that use X.509 
DN, and others that use IP addresses, and others that use just UTF-8, and no
interoperation between them is possible.

-- 
Nikos Mavrogiannopoulos

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 Oct 2004 21:13:52 -0700

> certificate authenticated PSK. 

How common are DSS-only servers? Does anyone even issue DSS certs?

> interoperation between them is possible.

I'm not sure this is a problem since the keys are manually configured
anyway...

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 21 Oct 2004 20:22:56 +0200

On Thursday 21 October 2004 06:13, Eric Rescorla wrote:

> > Certainly but my point also is, if certificate authenticated RSA
> > ciphersuites are added, then why the DHE_RSA/DHE_DSS are not added as
> > well? A server with a DSS only certificate can only use DHE_DSS, so is
> > not entitled to use certificate authenticated PSK.

In HTTP servers RSA is the only algorithm used.  But since PSK is not for them 
there is no reason to prohibit it.

-- 
Nikos Mavrogiannopoulos

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Oct 2004 17:05:48 -0700

> there is no reason to prohibit it.

It's not a matter of prohibiting it. It's a matter of whether our
policy is to provide the combinatoric explosion of all algorithms
every time we introduce something new. I consider that a bad policy.
So, if DSS isn't widely used, then I don't think it's particularly
important to provide a cipher suite number.

-Ekr