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

Bodo Moeller <bmoeller@acm.org> Fri, 21 July 2006 12:23 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3u2G-0003EI-QE; Fri, 21 Jul 2006 08:23:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3u2F-0003DL-Hd for tls@ietf.org; Fri, 21 Jul 2006 08:23:15 -0400
Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3tuu-0007cG-SO for tls@ietf.org; Fri, 21 Jul 2006 08:15:42 -0400
Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1G3tut2h77-0003z3; Fri, 21 Jul 2006 14:15:39 +0200
Received: by tau.invalid (Postfix, from userid 1000) id 5DDED17D1B; Fri, 21 Jul 2006 14:15:37 +0200 (CEST)
Date: Fri, 21 Jul 2006 14:15:37 +0200
From: Bodo Moeller <bmoeller@acm.org>
To: Pasi Eronen <pasi.eronen@nokia.com>
Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-psk-null-00.txt
Message-ID: <20060721121537.GA30405@iota.site>
References: <20060721093938.GA21125@iota.site> <000101c6acbb$ab8d64f0$d62915ac@NOE.Nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <000101c6acbb$ab8d64f0$d62915ac@NOE.Nokia.com>
User-Agent: Mutt/1.5.9i
X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

On Fri, Jul 21, 2006 at 02:49:06PM +0300, Pasi Eronen wrote:
> Bodo Moeller wrote:

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

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

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.



_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls