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.
- Re: [TLS] PSK in 1.3? Yoav Nir
- [TLS] PSK in 1.3? Manuel Pégourié-Gonnard
- Re: [TLS] PSK in 1.3? Ilari Liusvaara
- Re: [TLS] PSK in 1.3? Eric Rescorla
- Re: [TLS] PSK in 1.3? Ilari Liusvaara
- Re: [TLS] PSK in 1.3? Manuel Pégourié-Gonnard
- Re: [TLS] PSK in 1.3? Yoav Nir
- Re: [TLS] PSK in 1.3? Hauke Mehrtens
- Re: [TLS] PSK in 1.3? Manuel Pégourié-Gonnard
- Re: [TLS] PSK in 1.3? Hauke Mehrtens
- Re: [TLS] PSK in 1.3? Watson Ladd
- Re: [TLS] PSK in 1.3? Jeffrey Walton
- Re: [TLS] PSK in 1.3? Paul Bakker
- Re: [TLS] PSK in 1.3? Eric Rescorla
- Re: [TLS] PSK in 1.3? Eric Rescorla
- Re: [TLS] PSK in 1.3? Dan Harkins
- Re: [TLS] PSK in 1.3? Watson Ladd
- Re: [TLS] PSK in 1.3? Dan Harkins
- Re: [TLS] PSK in 1.3? Manuel Pégourié-Gonnard
- Re: [TLS] PSK in 1.3? Manuel Pégourié-Gonnard
- Re: [TLS] PSK in 1.3? Dan Harkins
- Re: [TLS] PSK in 1.3? Watson Ladd
- Re: [TLS] PSK in 1.3? Peter Gutmann
- Re: [TLS] PSK in 1.3? Manuel Pégourié-Gonnard
- Re: [TLS] PSK in 1.3? Dan Harkins
- Re: [TLS] PSK in 1.3? Mohamad Badra
- Re: [TLS] PSK in 1.3? Peter Gutmann
- Re: [TLS] PSK in 1.3? Peter Gutmann
- Re: [TLS] PSK in 1.3? Yoav Nir
- Re: [TLS] PSK in 1.3? Viktor Dukhovni
- Re: [TLS] PSK in 1.3? Dan Harkins
- Re: [TLS] PSK in 1.3? Ilari Liusvaara
- Re: [TLS] PSK in 1.3? Sven Schäge
- Re: [TLS] PSK in 1.3? Christian Kahlo
- Re: [TLS] PSK in 1.3? Dan Harkins
- Re: [TLS] PSK in 1.3? John Mattsson
- Re: [TLS] PSK in 1.3? Alex Elsayed
- Re: [TLS] PSK in 1.3? Dan Harkins
- Re: [TLS] PSK in 1.3? Dan Harkins
- Re: [TLS] PSK in 1.3? Viktor Dukhovni
- Re: [TLS] PSK in 1.3? Stephen Checkoway
- Re: [TLS] PSK in 1.3? Dan Harkins
- Re: [TLS] PSK in 1.3? Stephen Checkoway
- Re: [TLS] PSK in 1.3? Dan Harkins
- Re: [TLS] PSK in 1.3? Stephen Checkoway
- Re: [TLS] PSK in 1.3? Viktor Dukhovni
- Re: [TLS] PSK in 1.3? Watson Ladd