Subject: [TLS] issues with DTLS + PSK

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 05 Jan 2015 17:08:14 +0100

Some issues while using PSK in combination with DTLS.
1. The PSK ciphersuites rely on Finished messages mismatch to detect a
wrong preshared-key. That doesn't work well with DTLS where wrongly
encrypted messages are simply ignored. Thus there is no reasonable way
to detect wrong PSK keys except wait for some timeout.

2. Even if one would not ignore the finished message decryption issue,
and fail the handshake immediately, there is no way to notify the peer
of the failure. The exchanged keys don't match, so any alert message
will not be received by the peer.

A solution would be, on a revision of the PSK ciphersuites, to define
PSK ciphersuites which will authenticate (e.g., with a MAC), an (EC)DH
key exchange. That would allow a graceful failure in case of a mismatch
of keys. In addition it will allow the usage of hardware security
modules with PSK (something that is very hard to impossible with the
current ECDHE/DHE PSK ciphersuites).

regards,
Nikos

---

From: Martin Thomson <[email-masked]>
Date: Mon, 5 Jan 2015 09:42:55 -0800

> current ECDHE/DHE PSK ciphersuites).

If the same general formulation we've been using for TLS 1.3 is
consistently applied to PSK, then key derivation will be based on the
(EC)DH exchange and the PSK will only be used to authenticate, exactly
as you describe.  I think that would be a pretty good answer.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 05 Jan 2015 19:26:11 +0100

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.

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.

Ciao
Hannes

On 01/05/2015 05:08 PM, Nikos Mavrogiannopoulos wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 5 Jan 2015 10:41:17 -0800

> loose all the performance and code size benefits that the PSK mechanism

The theory that I've heard regarding this was that we might have two modes:

1. A PSK that mapped directly into session resumption (i.e., you are
"resuming" some non-existent session).

2. A PSK that followed the full handshake with DH.

While the latter is certainly slow and expensive, I think it was
Carsten who suggested that some IoT devices would be interested in -
occasionally - doing an ephemeral handshake.  Forward secrecy was a
desirable property, and some devices would be able to do the work as
long it was infrequent and there were no time-critical functions in
progress.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 05 Jan 2015 19:47:06 +0100

Hi Martin,

I was talking about PSK is used today in DTLS 1.2. Of course, in the
future (with TLS/DTLS 1.3) it might look differently and approach
mentioned below with #1 makes sense to me.

Ciao
Hannes

---

From: Martin Thomson <[email-masked]>
Date: Mon, 5 Jan 2015 10:55:16 -0800

> mentioned below with #1 makes sense to me.

Maybe it's just me, but I don't see much point in addressing the sort
of concerns Nikos has in TLS 1.2 or earlier :)

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 06 Jan 2015 09:43:34 +0100

> 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.

> 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.

regards,
Nikos