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

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

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3wUt-0006H8-TD; Fri, 21 Jul 2006 11:00:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3wUt-0006H3-8s for tls@ietf.org; Fri, 21 Jul 2006 11:00:59 -0400
Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3wUr-0003CP-Kq for tls@ietf.org; Fri, 21 Jul 2006 11:00:59 -0400
Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1G3wUp3zs8-0000sG; Fri, 21 Jul 2006 17:00:56 +0200
Received: by tau.invalid (Postfix, from userid 1000) id 122D81895D; Fri, 21 Jul 2006 17:00:54 +0200 (CEST)
Date: Fri, 21 Jul 2006 17:00:54 +0200
From: Bodo Moeller <bmoeller@acm.org>
To: Eric Rescorla <ekr@networkresonance.com>
Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-psk-null-00.txt
Message-ID: <20060721150054.GA15450@iota.site>
References: <20060721093938.GA21125@iota.site> <000101c6acbb$ab8d64f0$d62915ac@NOE.Nokia.com> <20060721121537.GA30405@iota.site> <86u05b10us.fsf@raman.networkresonance.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <86u05b10us.fsf@raman.networkresonance.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: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: Pasi Eronen <pasi.eronen@nokia.com>, 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 07:36:27AM -0700, Eric Rescorla wrote:
> Bodo Moeller <bmoeller@acm.org>; writes:

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

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



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