Subject: [Lwip] Notes on draft-tschofenig-lwig-tls-minimal-03

From: Hauke Mehrtens <[email-masked]>
Date: Wed, 31 Jul 2013 14:35:36 +0200

Hi Hannes,

I have some notes on
https://tools.ietf.org/html/draft-tschofenig-lwig-tls-minimal-03

I am working on tinyDTLS and came across some problems. I extended it to
support raw public keys with TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 on the
SECP256R1 curve. The ECC code just supports this specific curve.

The ClientHello without a cookie is now 99 Bytes big (value in UDP
header) and on ieee802.15.4 it has to be fragmented somewhere. But to do
fragmentation we have to store a state somewhere.

For retransmission, instead of storing the whole message you could store
the data which is needed to recreate the message. Data like the server
certificate already has to be stored somewhere. I am planing to
implement this.

We have a high memory consumption in the handshake process, you could
make it possible to be able to just do one handshake at a time, but have
more than one DTLS session open at a time. All these DTLS session will
then share a common memory space to store their temporary handshake
data. I am planing to implement this.

If you have a pretty reliable medium you could leave out implementation
of reordering, the other peer will resend the messages if a message will
be lost and then the client could start at the position where the
package was lost again. This could save some ram to store the messages.

Is the code of the modified tinyDTLS version and a more detailed
description of the setup available somewhere? I am planing to so some
measurements with tinyDTLS and raw public keys. How was the RAM size
measurement done?

As already discussed in the meeting the sizes for the tls implementation
are pretty big. I haven't implemented a generic ASN.1 parser, I am just
supporting one type of raw public key, so I am doing a memcmp() to
ensure it is the one I excepted, then there is the public key at a
constant offset.

My tinyDTLS implementation with raw public keys and
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 on the SECP256R1 curve is about 30%
bigger then the version just supporting PSK cipher. This measurement was
done on a AMD64 system without any compiler optimization for size. I am
planing to do a better measurement.

Hauke

[0]: https://github.com/hauke/tinydtls/tree/ecdh-merge