Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-psk-null-00.txt

From: Bodo Moeller <[email-masked]>
Date: Fri, 21 Jul 2006 11:39:38 +0200

On Thu, Jul 20, 2006 at 06:50:01PM -0400, [email-masked] wrote:

> 	Title		: Pre-Shared Key Cipher Suite with NULL Encryption for Transport Layer Security 
> 	Author(s)	: U. Blumenthal, P. Goel
> 	Filename	: draft-ietf-tls-psk-null-00.txt
> 	Pages		: 5
> 	Date		: 2006-7-20
> 	
>    This document specifies authentication-only cipher suites for the 
>    Pre-Shared Key based [TLS-PSK] Transport Layer Security (TLS) [TLS] 
>    protocol to support null encryption. These cipher suites are useful 
>    for countries and places with cryptography-related restrictions.  

> http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-null-00.txt

The new I-D contains three ciphersuites:

    TLS_PSK_WITH_NULL_SHA
    TLS_DHE_PSK_WITH_NULL_SHA
    TLS_RSA_PSK_WITH_NULL_SHA

Is there a good case for definining a DHE_PSK ciphersuite with NULL
encryption?  RSA_PSK involves server certificates, so it does not
solely rely on pre-shared keys for authentication.  DHE_PSK, however,
uses ephemeral Diffie-Hellman without certificate-based
authentication.  This is very useful when the key exchange is used to
obtain keys for symmetric encryption.  However, in these NULL
encryption ciphersuites, the key exchange is only used to derive
authentication keys, so there is only a very limited need for forward
security.  (DHE_DSK, when using NULL encryption, provides protection
against exposure of a pre-shared key if use of said key has been
stopped, but TLS session based on the key remain active.)

If we are going to allocate additional ciphersuite numbers for new PSK
ciphersuites, other key exchange mechanisms for use with symmetric
encryption would appear more useful to me than DHE_PSK for NULL
encryption: RFC 4247 does not have any DHE_RSA_PSK and EDH_DSS_PSK
methods, which would combine ephemeral Diffie-Hellman with RSA or DSA
certificates -- thus providing both forward security and
certificate-based server authentication.  I don't know if this variant
is really needed (probably so rarely that combining multiple different
key exchange methods via renegotiation is a more reasonable technique
than specifying another set of specific ciphersuites), but it
certainly looks more useful to me than TLS_DHE_PSK_WITH_NULL_SHA!

So currently I think we should cut down the I-D to only two
ciphersuites, TLS_PSK_WITH_NULL_SHA and TLS_RSA_PSK_WITH_NULL_SHA.

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

---

From: "Pasi Eronen" <[email-masked]>
Date: Fri, 21 Jul 2006 14:49:06 +0300

> stopped, but TLS session based on the key remain active.)

With DHE_PSK, a passive eavesdropper doesn't get the information
required for a dictionary attack against the PSK.

So it might be useful even with NULL encryption in some environments
(where active MitM is not considered a significant threat, and the PSK
is not guaranteed to be "strong enough"). I'm not sure how common
those environments would be, but then again, I didn't think that
anyone would want NULL encryption either...

Best regards,
Pasi

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 21 Jul 2006 14:15:37 +0200

> anyone would want NULL encryption either...

OK, DHE_PSK can help for low-entropy passwords -- which you shouldn't
use, but which we shouldn't rely on not being used, I guess.  This
makes sense, but warrants explanation in the Security Considerations
section.  The Security Considerations ought to point out that

- DHE_PSK helps only if RSA_PSK and plain PSK ciphersuites are
  disabled (otherwise the adversary needs only a single connection
  attempt from a client to a rogue server to get data for a dictionary
  attack), and

- small subgroup attack countermeasures are required even though there
  is no DH key reuse.

  RFC 4346 mentions small-subgroup attacks, but only says that the
  need to be prevented when "the same DH keypair is to be used to
  prevent small subgroup attacks".  This makes sense for DH as used in
  the usual TLS ciphersuites, but the DHE ciphersuites from RFC 4279
  have stronger requirements if they are to be used as a dictionary
  attack countermeasure.  If the client does not check for small
  subgroups, then a single connection attempt to a rogue server can
  provide the server with the data needed for a dictionary attack,
  essentially like in plain PSK ciphersuites.  

This (at least the latter) is actually a bug report for RFC 4279, not
just for the new I-D.

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 21 Jul 2006 17:00:54 +0200

On Fri, Jul 21, 2006 at 07:36:27AM -0700, Eric Rescorla wrote:
> Bodo Moeller <[email-masked]> writes:

> I just woke up so I may be kind of slow, but I'm not sure I 
> understand why small subgroups make this problem any worse.
> If the client connects to a rogue server, the server uses
> a DH pair of his choice and so gets the client to give
> him a value that's a function of ZZ (known) and the 
> PSK. Why is this any easier with a small subgroup?
> It's true that with a small subgroup the server can force
> ZZ to a specific value, but since the PSK calculation
> gets salted with the randoms, I'm not sure why that
> matters.

With a low-entropy pre-shared key and without DH, there is plenty of
randomness in the calculations, but most of this is openly
transmitted.  Only the PSK is hidden, which is why plain PSK
ciphersuites allow for offline dictionary attacks.

Enter DH.  This allows us to have a lot more randomness in the
protocol that is not openly transmitted, thus providing protection
against passive dictionary attacks.

However, if the server can arrange the DH result ZZ to be a specific
value (such as 1 or p-1) by using small subgroups, that hidden
randomness in the DH exchange no longer affects the final key exchange
result.  Only the openly transmitted randomness and the PSK remain
effective, so the server can try different guesses for the PSK in an
offline dictionary attack after having received the client's
"Finished" from this handshake.  So there's the dictionary attack
again, almost as if DH wasn't even in the protocol.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 21 Jul 2006 08:14:30 -0700

> again, almost as if DH wasn't even in the protocol.

But in order for the server to do this, it needs to be part
of the protocol, which means that it would have access
to the hidden randomness anyway. The attack you describe
is a single active attack + offline computation, just as
in the ordinary DH case.

-Ekr

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 21 Jul 2006 17:29:05 +0200

> is a single active attack + offline computation, just as

Oops, yes, you are right.  DHE_PSK can only provide protection against
dictionary attacks if no client ever uses the pre-shared key in a
connection to an adversarial server.  With an active attacker, all
bets are off anyway.

---

From: "Ron Teitelbaum" <[email-masked]>
Date: Fri, 21 Jul 2006 19:43:34 -0400

Hi All,

Sorry about the OT spam.  I'm having some trouble with a server hello, it
looks properly formed but when I send it back to a browser it errors out.  

Can anyone suggest a TLS Developers list I could ask questions on or any
other reading I should do about the actual format or examples of the TCP
that is sent back in the server hello.  Suggestions about other tools that
would help to debug the problem on a windows environment would also be very
much appreciated.

Thank you,

Ron Teitelbaum
President / Principal Software Developer
US Medical Record Specialists
[email-masked] 

My ServerHello:

a ByteArray(22 3 1 0 75 2 0 0 71 3 1 32 1 133 226 6 25 8 52 139 232 174 232
214 178 59 212 53 40 179 41 3 198 102 25 120 169 92 56 219 169 27 54 52 32
107 191 163 205 21 34 82 15 149 50 249 200 178 121 78 219 88 43 135 114 222
238 60 227 43 11 54 168 168 59 53 241 0 10 0)

hex:
'160301004B020000470301200185E2061908348BE8AEE8D6B23BD43528B32903C6661978A95
C38DBA91B3634206BBFA3CD1522520F9532F9C8B2794EDB582B8772DEEE3CE32B0B36A8A83B3
5F1000A00'