Re: [TLS] PSK in 1.3?

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 24 February 2015 03:40 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 E52F41A010F for <tls@ietfa.amsl.com>; Mon, 23 Feb 2015 19:40:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 C-_7QHeGcFT8 for <tls@ietfa.amsl.com>; Mon, 23 Feb 2015 19:40:45 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41DA51A00FF for <tls@ietf.org>; Mon, 23 Feb 2015 19:40:45 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A51EC282F52; Tue, 24 Feb 2015 03:40:43 +0000 (UTC)
Date: Tue, 24 Feb 2015 03:40:43 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150224034043.GT1260@mournblade.imrryr.org>
References: <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> <CAO9bm2mQzjiLpMgB-mh-bRca-A2gkTZiBd9c3CsFq4kekBGxUw@mail.gmail.com> <07df9eeefbc1738ea645d72d0afb35b5.squirrel@www.trepanning.net> <mc9gjp$7nv$1@ger.gmane.org> <5f40f09f6b0268a455f281297c971708.squirrel@www.trepanning.net> <AA125A16-FD73-42C2-B196-89FFC6E9ED92@pahtak.org> <ab84dca54551eee2f845f6fb0274d6c1.squirrel@www.trepanning.net> <62A56053-48BD-44E2-838F-2B5FAA709274@pahtak.org> <3ce50aefd478490a025d7ff9942d6bf0.squirrel@www.trepanning.net> <5624F480-B31D-47FC-8CA7-0D879B3E934D@pahtak.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5624F480-B31D-47FC-8CA7-0D879B3E934D@pahtak.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/CAu9OwWqg5gEPgQP11K1l3n0hrU>
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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: <http://www.ietf.org/mail-archive/web/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: Tue, 24 Feb 2015 03:40:47 -0000

On Mon, Feb 23, 2015 at 10:08:16PM -0500, Stephen Checkoway wrote:

> > It is obvious that a making n large enough can make a dictionary attack
> > moot. I have not said otherwise. It just doesn't make _the protocol_
> > resistant to dictionary attack.
> 
> This isn't a useful distinction then since no mode of TLS is resistant to dictionary attacks by what I take to be your definition.

I'd like to suggest that this thread is going nowhere at present.

I don't think any of the below are controversial.

    * PSK is vulnerable to dictionary attacks when poor key management
      leads to a reduced key space.

    * PAKE protocols offer greater resistance to off-line dictionary
      attacks.

    * PSK *with properly selected keys* is secure in practice, once
      the brute force search is at least as expensive as brute-forcing
      the symmetric-algorithm keyspace.

    * No key management approach is perfect.

At which point it makes sense to step back and decide whether the
risk of reduced key-space with PSK warrants dropping support, even
though other approaches that are staying also have potential flaws.

Is there a suitable PAKE that is ready to replace all applications
of PSK?  Is it practical in all the environments that would otherwise
opt to use PSK?  If PSK is simply an obsolete needlessly weaker
shared secret system, then good riddance.  If not, then the discussion
should be about why PSK is more practical despite its limitations.

-- 
	Viktor.