1. Small(er) Footprint for TLS Implementations Hannes Tschofenig Smart Object Security workshop, March 2012, Paris

2. How do the communication relationships look like? For example: Does your smart object talk to only a small set of pre-defined servers?

3. Following the recommendations in RFC 4101 “Writing Protocol Models” helps to make these important design aspect transparent.

4. What security threats do you care about? What security services do you have to offer?

5. RFC 3552 “Guidelines for Writing RFC Text on Security Considerations” offers valuable guidance.

6. TLS (or DTLS) may be the right building block for your problem; it also offers a lot of flexibility. Different credentials (pre-shared secrets, passwords, asymmetric crypto, etc.) Various authentication and key exchange protocols Numerous algorithms for usage with data traffic protection Session Resumption (with and without server-side state) Alternative key validation techniques Possibility to replace record layer

7. Unfortunately, there is no magic! Lower footprint means fewer functions or more dependencies/assumptions

8. Note: The code was compiled under Ubuntu Linux using the -Os compiler flag setting for a 64- bit AMD machine.

9. Parts omitted by raw public key implementation