Re: [TLS] PSK in 1.3?

Hauke Mehrtens <hauke@hauke-m.de> Sun, 19 October 2014 13:41 UTC

Return-Path: <hauke@hauke-m.de>
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 384B61A0248 for <tls@ietfa.amsl.com>; Sun, 19 Oct 2014 06:41:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.262
X-Spam-Level:
X-Spam-Status: No, score=-1.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 an57WMNTeU8J for <tls@ietfa.amsl.com>; Sun, 19 Oct 2014 06:41:43 -0700 (PDT)
Received: from hauke-m.de (hauke-m.de [5.39.93.123]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69AB01A0242 for <tls@ietf.org>; Sun, 19 Oct 2014 06:41:43 -0700 (PDT)
Received: from [IPv6:2001:470:7259:0:656f:90e1:2bfd:7a52] (unknown [IPv6:2001:470:7259:0:656f:90e1:2bfd:7a52]) by hauke-m.de (Postfix) with ESMTPSA id DD7CF20106; Sun, 19 Oct 2014 15:41:41 +0200 (CEST)
Message-ID: <5443BF95.6090406@hauke-m.de>
Date: Sun, 19 Oct 2014 15:41:41 +0200
From: Hauke Mehrtens <hauke@hauke-m.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Yoav Nir <ynir.ietf@gmail.com>, Manuel Pégourié-Gon nard <mpg@polarssl.org>
References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com>
In-Reply-To: <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_kXPaIJThRl5eL2Bq0hbLQrSQoE
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: Sun, 19 Oct 2014 13:41:44 -0000

On 10/19/2014 03:03 PM, Yoav Nir wrote:
> As Ilari said, there are ciphersuites with PSK and FS. 
> 
> I don’t see what the rationale can be to allow non-PFS for PSK authentication, but prohibit it for certificate authentication.  That would imply that we can make a blanket statement that the data passed in PSK-authenticated sessions is inherently low-value or non-private.  I don’t think we can make that statement.

For using PFS some asymmetric cryptography is needed in addition to the
symmetric cryptography and without PFS only symmetric cryptography is
needed. For normal desktop usage this does not matter, but when you want
to use TLS and DTLS on some embedded devices like Class 1 node (see
rfc7228 section 3.) with ~ 10 KiB ram and ~ 100 KiB flash and a slow CPU
(~ 10MHz) without any hardware cryptography support a DTLS handshake
without PFS is possible in under two seconds while doing a handshake
with PFS with asymmetric cryptography like ECC would take more than 10
seconds or even minutes.
In addition adding ECC also adds some more code.

I tried a DTLS handshake between two simulated MSP430X and it took 3.3
seconds for the PSK handshake using TLS_PSK_WITH_AES_128_CCM_8 and it
took 336 seconds for a handshake using the
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite on the curve secp256r1
without client authentication and 499 seconds with client
authentication. The slow part was the elliptic curve multiplication
which took 47 seconds. (my code was not very optimized and this was a
very slow CPU)

Hauke