Re: [TLS] PSK in 1.3?

"Dan Harkins" <dharkins@lounge.org> Mon, 20 October 2014 19:20 UTC

Return-Path: <dharkins@lounge.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 8409F1AC3B2 for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 12:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.567
X-Spam-Level:
X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] 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 dRMrkModhF5e for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 12:20:23 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A6E0E1AC3C6 for <tls@ietf.org>; Mon, 20 Oct 2014 12:20:23 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 1742710224008; Mon, 20 Oct 2014 12:20:23 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 20 Oct 2014 12:20:23 -0700 (PDT)
Message-ID: <e1137dfbb54785a52e18b22a31b45357.squirrel@www.trepanning.net>
In-Reply-To: <54454F3C.7010305@polarssl.org>
References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> <CACsn0ck0FRHFek59A5+jxDkDGEtXPT8HejO3wO4HnYfHCw6hYg@mail.gmail.com> <74986741b83a76277b2fcfd1e74a75d4.squirrel@www.trepanning.net> <54454F3C.7010305@polarssl.org>
Date: Mon, 20 Oct 2014 12:20:23 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Manuel Pégourié-Gonnard <mpg@polarssl.org>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/w5p2tPY2On6VrB8GC23wNCeAa2o
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] PSK in 1.3?
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: <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: Mon, 20 Oct 2014 19:20:26 -0000

On Mon, October 20, 2014 11:06 am, Manuel Pégourié-Gonnard wrote:
> On 20/10/2014 19:06, Dan Harkins wrote:
>>   There is nothing to flesh out because you seem to not understand
>> what a dictionary attack is-- but you're in company because neither
>> did the editors of that RFC.
>>
>>   Protocols that use a static, symmetric credential like a PSK (or a
>> password, the difference is semantic) are all flawed because the
>> adversary is always assumed to have access to a pool from which
>> the PSK (or password is drawn. Resistance against dictionary attack
>> is then a demonstration that the advantage gained by the adversary
>> is due to _interaction_ and not _computation_.
>>
>>   Merely making the pool from which the PSK is drawn, for instance
>> by making it a bigger or including mixed case, etc, does not make
>> the protocol resistant to dictionary attack.
>
> From a theoretical standpoint, the PSK key exchange is indeed vulnerable
> to a
> dictionary attack with this definition. In practice, if your keys are
> 128-bit
> long and chosen uniformly at random using a good source of entropy, I
> doubt any
> real-world adversary is able to gain a non-negligible advantage in the
> foreseeable future.

  The justification for these ciphersuites is some constrained device that
has a small data and code size. But if you can not only generate 128-bit
long uniformly random keys from a good source of entropy and also
securely provision them on 2 (or more) devices then you don't need TLS.
Just do static keyed symmetric crypto and you save even more data
and code by eliminating TLS!

  In practice, these things are deployed by people who probably do not
read the RFC in question, are in a hurry, and don't understand the
security implications of their use of TLS. The PSKs that get provisioned
are the ones that are easy to enter with a low probability of error-- i.e.
something considerably less than uniformly random 128-bit key
generated from a good source of entropy.

  This is not (only) a theoretical issue. It's practical reality.

> Also, it should be noted that with this definition, the TLS session keys
> are
> vulnerable to a dictionary attack too. In practice, it's not a problem
> either
> for the same reason. Obviously the difference between the pre-shared key
> and the
> TLS session keys is that the later is short-term while the former is
> long-term.
> Which basically boils down to the point that PSK lacks FS.
>
> Are you sure you have point besides:
> - pre-shared key must be chosen with sufficient entropy and
> - PSK does not offer FS?

  Yes, I'm absolutely sure. It's:

  - you can't ensure security with MUSTs and SHALLs; and,
  - the use case that you say compels PSK ciphersuites actually argues
     against you.

TLS should be as misuse resistant as possible. That is, it should be as
hard as possible to use improperly and that means no PSK ciphersuites.

  regards,

  Dan.