Re: [TLS] issues with DTLS + PSK

Nikos Mavrogiannopoulos <> Tue, 06 January 2015 08:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7804D1A1F01 for <>; Tue, 6 Jan 2015 00:43:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nzXsTo1mHUin for <>; Tue, 6 Jan 2015 00:43:46 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 41E701A899D for <>; Tue, 6 Jan 2015 00:43:44 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id t068hb1R024670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 6 Jan 2015 03:43:37 -0500
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id t068hZ9C026088 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 6 Jan 2015 03:43:36 -0500
Message-ID: <>
From: Nikos Mavrogiannopoulos <>
To: Hannes Tschofenig <>
Date: Tue, 06 Jan 2015 09:43:34 +0100
In-Reply-To: <>
References: <> <>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on
Subject: Re: [TLS] issues with DTLS + PSK
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Jan 2015 08:43:48 -0000

On Mon, 2015-01-05 at 19:26 +0100, Hannes Tschofenig wrote:
> Hi Nikos,
> the issue you raise did not surface as a problem in the IoT space with
> the use of DTLS. When you do not have the right key for authentication
> in DTLS then waiting for the timeout is not going to be a big deal. Note
> that this is not a user sitting in front of the machine and typing in
> passwords. This is, as the name indicates, a shared secret-based mechanism.

My use case is not with unattended clients and the main issue as I see
it, is configuration. You cannot have instructions like put a key, and
if it works everything went well. Otherwise if you see random errors,
the key is wrong, or there is network issue, or whatever and go figure.
Of course that is still usable, but has a horrible debugging mechanism
in case of a failure.

> Using DTLS-PSK in combination with DH is IMHO not particularly useful
> since then you can also switch to a raw public key right away since
> you loose all the performance and code size benefits that the PSK
> mechanism provides with DTLS.

DHE-PSK is more efficient than DHE-RSA, and the same is for the ECDHE
equivalent, because you don't need digital signatures, only the key
exchange. Moreover, you don't need to drag or rely to an ASN.1 parser.