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

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 31 October 2015 14:29 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 553891B38DB for <tls@ietfa.amsl.com>; Sat, 31 Oct 2015 07:29:51 -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 O5MCqWMLxmrc for <tls@ietfa.amsl.com>; Sat, 31 Oct 2015 07:29:50 -0700 (PDT)
Received: from filtteri1.pp.htv.fi (filtteri1.pp.htv.fi [213.243.153.184]) by ietfa.amsl.com (Postfix) with ESMTP id E6BA51B38D6 for <tls@ietf.org>; Sat, 31 Oct 2015 07:29:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by filtteri1.pp.htv.fi (Postfix) with ESMTP id B936F21BBE2; Sat, 31 Oct 2015 16:29:48 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri1.pp.htv.fi [213.243.153.184]) (amavisd-new, port 10024) with ESMTP id THxhHChCeLLA; Sat, 31 Oct 2015 16:29:48 +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 smtp4.welho.com (Postfix) with ESMTPSA id 8FBB15BC010; Sat, 31 Oct 2015 16:29:48 +0200 (EET)
Date: Sat, 31 Oct 2015 16:29:46 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20151031142945.GA12815@LK-Perkele-V2.elisa-laajakaista.fi>
References: <5634A3B8.7070701@gmail.com> <CABcZeBPNHPzywr89wLgV4zWKjKXXk_kyxoV75pYOuuuK=QO9=A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABcZeBPNHPzywr89wLgV4zWKjKXXk_kyxoV75pYOuuuK=QO9=A@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/cxkMjhYSxi8jLQiA_JdrH_a-63A>
Cc: "tls@ietf.org" <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 14:29:51 -0000

On Sat, Oct 31, 2015 at 10:55:24PM +0900, Eric Rescorla wrote:
> Sam,
> 
> Thanks for posting this. It's great to see people doing real formal
> analysis of the TLS 1.3 draft; this is really helpful in guiding the design.
>
> This result motivates and confirms the need to modify the handshake hashes
> to contain the server Finished when we add post-handshake authentication
> as is done in PR#316, which of course we'll be discussing in Yokohama.
> I'd be very interested in learning of the results you get when you model
> that.

Looking at the issue at wider angle, this soundness hole appears anytime
handshake_messages and configuration do not jointly represent the static
secret (the inclusion of server Finished fixes it for client signature,
because server Finished represents the static secret).

If TLS ever gets mode that combines that non-representation with static
server certificate auth (no idea what such mode could be), one gets
problems with server auth.


-Ilari