Re: [TLS] PSK in 1.3?

Manuel Pégourié-Gonnard <mpg@polarssl.org> Mon, 20 October 2014 18:15 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 560381A8ABC for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 11:15:47 -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 0VAFPMcK7AAe for <tls@ietfa.amsl.com>; Mon, 20 Oct 2014 11:15:46 -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 C2F4C1A8AD6 for <tls@ietf.org>; Mon, 20 Oct 2014 11:15:28 -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=keK5UiD/QZ3uS7ijSnn4MS+5+7VQR8kwnxnPK5n4r3w=; b=axH09zxVRe1VdLmH7KLnKL9o8AvOGvEaFta2m3Vo0AWygM7YMClXzOCkUj34GZz3TzbuFChhnQNX/vH2tcTyDtvIdNd5uNODvBZdmkFWwn8kD9IU0mNCAmU59InThPWZWy1is5Hhh8CkL801Y3elfJwz2o4N1irmW9iLt+tTTC8=;
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 1XgHUE-0003y8-Uc; Mon, 20 Oct 2014 20:15:19 +0200
Message-ID: <5445513A.50703@polarssl.org>
Date: Mon, 20 Oct 2014 20:15:22 +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>, Watson Ladd <watsonbladd@gmail.com>
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>
In-Reply-To: <74986741b83a76277b2fcfd1e74a75d4.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/4c2e0K31FHeYMs6HV-l1TGz2enk
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 18:15:47 -0000

On 20/10/2014 19:06, Dan Harkins wrote:
>   Merely making the pool from which the PSK is drawn, for instance
> by making it a bigger or including mixed case

PS: the above reference to "mixed case" makes me think there is a serious
misunderstanding about how keys should be generated. They should be the output
of a properly seeded cryptographically secure DRBG. The very notion of "mixed
case" does not make any sense in this context.

If such misinterpretations can be made, then indeed the RFC should be revised to
be much more explicit about the meaning of pre-shared *key* (as opposed to
password).

Manuel.