Re: [TLS] Revision 10: possible attack if client authentication is allowed during PSK

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 31 October 2015 13:32 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3441B2BCF for <tls@ietfa.amsl.com>; Sat, 31 Oct 2015 06:32:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyP_C030i8cj for <tls@ietfa.amsl.com>; Sat, 31 Oct 2015 06:32:37 -0700 (PDT)
Received: from filtteri2.pp.htv.fi (filtteri2.pp.htv.fi [213.243.153.185]) by ietfa.amsl.com (Postfix) with ESMTP id 1C10A1B2BBF for <tls@ietf.org>; Sat, 31 Oct 2015 06:32:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by filtteri2.pp.htv.fi (Postfix) with ESMTP id 7E27319BD3A; Sat, 31 Oct 2015 15:32:34 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri2.pp.htv.fi [213.243.153.185]) (amavisd-new, port 10024) with ESMTP id RV31YzhjPl77; Sat, 31 Oct 2015 15:32:34 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id 5539C5BC00A; Sat, 31 Oct 2015 15:32:34 +0200 (EET)
Date: Sat, 31 Oct 2015 15:32:31 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Sam Scott <sam.scott89@gmail.com>
Message-ID: <20151031133231.GB12538@LK-Perkele-V2.elisa-laajakaista.fi>
References: <5634A3B8.7070701@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <5634A3B8.7070701@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/AiGB0JVrj7Wf3eC2SI35L01osVw>
Cc: tls@ietf.org
Subject: Re: [TLS] Revision 10: possible attack if client authentication is allowed during PSK
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Oct 2015 13:32:39 -0000

On Sat, Oct 31, 2015 at 11:19:20AM +0000, Sam Scott wrote:
> Dear all,
> 
> While revision 10 does not yet appear to permit certificate-based client
> authentication in PSK (and in particular resumption using PSK), we modelled
> what we believe is the intended functionality.

Eh, I thought that using static client certificate auth with PSK is not
supposed to be possible.

BTW: TLS 1.2 doesn't seem to explicitly prohibit client auth with PSK, and
if client and server try to use client certs with PSK, bad things happen...

> While the modifications proposed in PR#316 [4] explicitly allow client
> authentication in these contexts, the PR also redefines the client signature
> based on a new "Handshake Context" value which includes the server Finished
> message. Intuitively, this new definition appears to address the attack
> because the attacker cannot transplant the Finished message between
> connections. We are currently working towards a Tamarin proof that PR#316
> indeed prevents our attack.

By my reading, #316 does not permit static client authentication with
PSK (it only permits dynamic auth, which didn't even exist previously),
most definitely not explicitly.

Also, found out that -10 looks to be at least unclear about if the
server Finished is included in the data to be signed or not...

I also searched when this got broken. Looks to be part of "DH-based
key exchange" changes in -07 (in -06, hashes definitely did include
finished messages).


-Ilari