The call for adoption ended with no objections. =

@authors, please submit the document as a working = group document.

Thanks,

Cochairs.

From:= = lwip-bounces@ietf.org [mailto:lwip-bounces@ietf.org] On Behalf Of = Cao Zhen (CZ)
Sent: Thursday, August 22, 2013 8:42 = PM
To: lwip@ietf.org
Subject: [Lwip] Call for = adoption of = draft-tschofenig-lwig-tls-minimal-03

Hello Everyone, =

Berlin meeting witnessed a = meeting room consensus to adopt the DTLS minimal implementation guidance = draft http://tools.ietf.org/html/draft-tschofenig-lwig-tls-minimal-03.txt

This message would like to = confirm the consensus on the mailing list. Please help to feedback = within one week, i.e., next Thursday, 8/29.

Support with and without = comments are both welcome.

Many = thanks,

-cz

I think that Tiny DTLS with raw public key support is good to have.

My question is: is the implementation following
draft-ietf-tls-oob-pubkey?

Regards,

Behcet

On Tue, Aug 27, 2013 at 5:52 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:

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: lwip@ietf.org ; hannes.tschofenig@gmx.net ; sandeep.kumar@philips.com
> 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
>

_______________________________________________
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip