Subject: Re: Protocol Action: 'Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)' to Proposed Standard

From: Francis Dupont <[email-masked]>
Date: Mon, 27 Jun 2005 17:02:19 +0200

In your previous mail you wrote:

   The IESG has approved the following document:
   
   - 'Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) '
      <draft-ietf-tls-psk-09.txt> as a Proposed Standard
   
=> this document seems to go in the wrong way: pre-shared secrets
are known to be weaker than certificates and TLS has already many
problems with its misuses (for instance no client verification or
poor server certificate validation).
 I remember a similar discussion about IKEv2 but in this case pre-shared
secrets were kept for compatibility... I can't see why no argument
against pre-shared secrets applies for the TLS case. Perhaps a security area
director can help me? BTW, I don't buy the "limited CPU power" argument
without real world examples.

Regards

[email-masked]

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 27 Jun 2005 09:45:49 -0700

At 5:02 PM +0200 6/27/05, Francis Dupont wrote:
>pre-shared secrets
>are known to be weaker than certificates

That statement is false for many common uses of preshared secrets and 
certificates. A preshared secret with even 80 bits of randomness is 
stronger than most certificates used for authentication today. (See 
RFC 3766 for the math behind this.)

>secrets were kept for compatibility...

This is also false. The archives of the IPsec Working Group show that 
there were many other reasons for supporting preshared secrets, 
including many administrative scenarios.

The two authentication mechanisms have quite different properties and 
each is appropriate in many settings. Saying one or the other is 
"known to be weaker" without examining the context, particularly on a 
general-purpose mailing list, will not help increase the security of 
the Internet.

--Paul Hoffman, Director
--VPN Consortium

---

From: Francis Dupont <[email-masked]>
Date: Tue, 28 Jun 2005 14:11:51 +0200

=> my argument was not about key length but about the mechanisms
(i.e., computer science, not mathematics). Pre-shared secrets are
by definition at two places: this is enough to make the mechanism
weaker than asymmetric crypto. I can develop about the problem
to communicate the shared secret but in fact what I'd like to mean
is that pre-shared secrets are for good and less good reasons
perceived as weaker than certificates so the document in last call
can be preceived as a security regression.

   
=> I should be more accurate but my purpose was to launch a short discussion:
the compatibility was not a technical one but an operational one.
To summary my feeling is that IKEv1 is deployed at 90% with pre-shared
secrets and IKEv2 had to support them in order to be sold to current
IKEv1 administrators.

BTW there are other good examples where both mechanisms can be used
with a "public opinion advantage" for the asymmetric crypto one.
TKEY (RFC 2930) and SIG(0) (RFC 2931) is the first example which crosses
my mind.

=> I am not (yet) convinced that to accept the document will help
to decrease the security of the Internet but clearly I'd like to be
reassured/comforted and I am afraid your arguments have not worked...

Regards

PS: for instance I'd like to understand why self-signed certificates
were rejected, cf section 1.1 "Applicability statement". This is the
second part of my concern: is the domain of application large enough?