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
- Re: [TLS] I-D ACTION:draft-ietf-tls-psk-null-00.t… Bodo Moeller
- RE: [TLS] I-D ACTION:draft-ietf-tls-psk-null-00.t… Pasi Eronen
- Re: [TLS] I-D ACTION:draft-ietf-tls-psk-null-00.t… Bodo Moeller
- Re: [TLS] I-D ACTION:draft-ietf-tls-psk-null-00.t… Bodo Moeller
- Re: [TLS] I-D ACTION:draft-ietf-tls-psk-null-00.t… Eric Rescorla
- Re: [TLS] I-D ACTION:draft-ietf-tls-psk-null-00.t… Bodo Moeller
- [TLS] Suggestion for TLS Developer List Ron Teitelbaum