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

[Sye Loong Keoh <[e-mail]>]

Hi Hauke,

Just to follow up on your previous discussion, how's your progress on the TinyDTLS implementation on the TI MSP430?
Do you have already have performance results that can be shared with us, by incorporating them into the Hitchhiker's guide LWIG document (http://www.ietf.org/internet-drafts/draft-ietf-lwig-tls-minimal-00.txt)?

Cheers
Sye Loong

-----Original Message-----
From: Hauke Mehrtens [mailto:[e-mail]] 
Sent: Wednesday, 28 August, 2013 6:53 AM
To: Sye Loong Keoh
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: [SPAM?] Re: [SPAM?] Re: [Lwip] Notes on draft-tschofenig-lwig-tls-minimal-03

Hi Sye Loong,

I am using a simulated sensor node in cooja. wismote is a simulated wireless sensor node which simulates a TI MSP430 with 16kB RAM and 128 kB Rom, so this suites in the class 1 category.
Currently I am still in the state of getting tinydtls working on the TI MSP430.

Hauke

On 08/27/2013 03:32 AM, Keoh, Sye Loong wrote:
> Hi Hauke,
> 
> What is a wismote? Do you have a use case for your work? and what are 
> the assumptions of the nodes in your network? Are they class 1 devices 
> as defined in the Terminology draft?
> 
> Great that you are willing to contribute!
> 
> cheers
> Sye Loong
> 
> -----Original Message----- From: Hauke Mehrtens
> Sent: Monday, August 26, 2013 10:42 PM
> To: Sye Loong Keoh
> Cc: [e-mail] ; [e-mail] ; 
> [e-mail]
> Subject: [SPAM?] Re: [Lwip] Notes on 
> draft-tschofenig-lwig-tls-minimal-03
> 
> Hi Sye Loong,
> 
> I am currently at implementing reordering, it seams to work, but it is 
> not committed to github yet.
> 
> I am also sending only one message at a time, so a flight contains 
> many UDP packages.
> 
> I am currently trying to get it to work in cooja on a simulated 
> wismote, the psk handshake already works, but I still have problems 
> with the ECDH_ECDSA handshake, something is probably wrong in the ecc 
> code, on
> x86 it works. Cooja also has a nice tool which shows the stack usage 
> of the application running.
> 
> Too bad you can not give me access to your modified tinydtls version.
> 
> Most of my code is at github, it misses some of the things that I am 
> currently working on and that are not cleaned up right now.
> 
> I want to do some measurements similar to the ones, you did for the 
> psk case with ECDH_ECDSA for my master's thesis and I would like to 
> get them integrated into the draft.
> 
> Hauke
> 
> On 08/26/2013 12:04 PM, Keoh, Sye Loong wrote:
>> Hi Hauke,
>>
>> Thank you for your interest in our draft. It is great to hear that 
>> you are extending TinyDTLS with raw public key support, and this is 
>> indeed the contribution that we needed in this document, as we only 
>> had performance and implementation details of PSK in TinyDTLS.
>>
>> At least in your implementation, we needed the re-ordering because 
>> messages were not sent using message flights. Each message is sent 
>> individually.
>>
>> I am sorry that the the modified TinyDTLS code cannot be made 
>> available due to some constraints that we have. But, we can discuss 
>> specific needs that you have.
>> When you compile and flash the application to the hardware, you can 
>> get the RAM size measurement.
>>
>> Would be great if you could share your implementation details and 
>> measurements with us, so that they can be incorporated into our 
>> Internet Draft.
>>
>> cheers
>> Sye Loong
>>
>>>>>
>> 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
>