Re: [TLS] PSK in 1.3?

Manuel Pégourié-Gonnard <mpg@polarssl.org> Mon, 20 October 2014 20:26 UTC

Return-Path: <mpg@polarssl.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 1D22B1ACDF4 for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 13:26:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level:
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 Q30hmqtlrn4m for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 13:26:50 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3FB1ACDFA for <tls@ietf.org>; Mon, 20 Oct 2014 13:26:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=7MUp7p7qbWjzFUGIjkq3pofDYSAPlM7ezPozeqcGN0w=; b=f+FOeJlO5ygGUcqwjOWzeVdN1BOGC+pWAu4iRUOOykc/4DLQKUULJZD3BTBh3DO2FPqAnRJflgh62yIk+C3vfo/lDYLDzDHBdYcvbxgntorV7smTbXgLKZuKBI1b2ohhNII3cQPkYDka/XiUwb5FJDtm39OJObvIxIiENFyZP5I=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1XgJXO-000481-1p; Mon, 20 Oct 2014 22:26:42 +0200
Message-ID: <54457005.3040107@polarssl.org>
Date: Mon, 20 Oct 2014 22:26:45 +0200
From: Manuel Pégourié-Gonnard <mpg@polarssl.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Dan Harkins <dharkins@lounge.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> <e1137dfbb54785a52e18b22a31b45357.squirrel@www.trepanning.net>
In-Reply-To: <e1137dfbb54785a52e18b22a31b45357.squirrel@www.trepanning.net>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Vw80w0uPWoT4JOAtxb-F3ZOPG14
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 20:26:53 -0000

On 20/10/2014 21:20, Dan Harkins wrote:
>   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 addition to what Watson said, it's generally a bad idea to roll one's own
crypto protocol, it's too easy to get things wrong. Even with PSK, TLS brings
you important things: a record protocol, a way to derive session keys from the
long-term secret key, etc.

>   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.
> 
I agree that's a real problem. But I don't think it has anything to do with your
previous definition of dictionary attack. As you said earlier, the size of the
pool from which the key is drawn does not change the fact the a protocol is or
isn't resistant to dictionary attack. My impression is that the size of the pool
(or more precisely the entropy of the key generator) is exactly the problem (and
from my understanding of your previous paragraph, we at least agree that it's an
important question).

>   - you can't ensure security with MUSTs and SHALLs; and,

That's one point I certainly agree with.

> 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.
> 
I agree about misuse resistance, and I agree it's a serious problem with the PSK
ciphersuites. I'm just not sure if it's serious enough to get rid of them.

I'd like to point out again that, in contrast with the NULL ciphersuites for
example, the mere existence of the PSK suites is less of a threat for the rest
of TLS, since there is very little risk of them being silently selected by
mistake. The problem is people who choose to use PSK but do it badly, but it
does not affect people who don't choose to use PSK.

Anyway, it's good to be discussing this explicitly.

Manuel.