Subject: Re: [Dtls-iot] review up to section 4

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 06 Mar 2015 20:35:48 +0100

Hi Thomas,

thanks for proofreading. All comments addressed but a few questions below.

> *From:*FOSSATI, Thomas (Thomas) [mailto:[email-masked]]
> *Sent:* 05 March 2015 18:38
> *To:* Hannes Tschofenig
> *Subject:* review up to section 4
> 
>  
> 
> Hi Hannes, a first batch of comments.  Will continue later tonight.
> 
> Cheers, t
> 
> =-=-=-=-=-=
> 
> *Abstract (restructured)*
> 
>  
> 
> A typical design pattern in Internet of Things (IoT) deployments sees a
> constrained device (i.e. sensor/actuator) making its resources available
> to other networked agents.
> 
>  
> 
> This document defines a Transport Layer Security (TLS) and Datagram TLS
> (DTLS) 1.2 profile specifically targeted to constrained devices that can
> be used to prevent eavesdropping, tampering, and message forgery of the
> exchanged data.
> 

[Hannes] I changed the intro based on earlier comments already to:

"
Abstract

   A common design pattern in Internet of Things (IoT) deployments is
   the use of a constrained device that collects data via sensor or
   controls actuators for use in home automation, industrial control
   systems, smart cities and other IoT deployments.

   This document defines a Transport Layer Security (TLS) and Datagram
   TLS (DTLS) 1.2 profile that offers communications security for this
   data exchange thereby preventing eavesdropping, tampering, and
   message forgery.  The lack of communication security is a common
   vulnerability in Internet of Things products that can easily be
   solved by using these well-researched and widely deployed Internet
   security protocols.
"

Would this work for you as well?

>  
> 
> *Introduction*
> 
>  
> 
> s/to make data available/to exchange data
> 
Changed.

> s/To make Internet protocols fit constrained devices/Fitting internet
> protocols into constrained devices

Fixed.

/
> 
> s/this document is inspired by the desire/the main goal for this
> document is/

Fixed.

> 
> s/the guidance in this document/the information contained in the
> following sections/

Fixed.

> 
> s/offers communication security for IoT applications/offers
> communication security services for generic IoT applications/
> 
Fixed.

> s/any new TLS/DTLS extensions/any new TLS/DTLS extension/
Fixed.

> 
> s/Internet of Things product development./Internet of Things product./
> 

Fixed.

>  
> 
> *Terminology*
> 
>  
> 
> s/which are small devices/which are made of small devices/
> 
>  
Fixed.

> 
> *TLS/DTLS Protocol Overview (partially restructured)*
> 
> The TLS protocol [RFC5246] provides authenticated, confidentiality- and
> integrity-protected communication between two endpoints.  The
> protocol is composed of two layers: the Record protocol, which sits on
> top of a reliable transport (e.g. TCP) and provides the basic framing
> and cryptographic processing to a number of higher layer protocols
> (Handshake, Alert, Application, Heartbeat, ChangeCipherSpec) each of
> which implements a different function. In particular, the Handshake
> protocol is run at the beginning of every TLS session and allows server
> and client to authenticate each other and negotiate the cryptographic
> keys and algorithms used throughout the session.
> 
>  

I now have two versions, namely the version Ludwig suggested and the
version you suggest. Tell me which one to use.

Version 1:

   The TLS protocol [RFC5246] provides authenticated, confidentiality-
   and integrity-protected communication between two endpoints.  The
   protocol is composed of two layers: the Record protocol, which sits
   on top of a reliable transport (e.g., TCP) and provides the basic
   framing and cryptographic processing to a number of higher layer
   protocols (Handshake, Alert, Application, Heartbeat,
   ChangeCipherSpec) each of which implements a different function.  In
   particular, the Handshake protocol is run at the beginning of every
   TLS session and allows server and client to authenticate each other
   and negotiate the cryptographic keys and algorithms used throughout
   the session.

Version 2:

   The TLS protocol [RFC5246] provides authenticated, confidentiality-
   and integrity-protected communication between two endpoints.  The
   protocol is composed of two layers: the Record Protocol and the
   Handshaking Protocols.  At the lowest level, layered on top of a
   reliable transport protocol (e.g., TCP), is the Record Protocol.  It
   provides connection security by using symmetric cryptography for
   confidentiality, data origin authentication, and integrity
   protection.  The Record Protocol is used for encapsulation of various
   higher-level protocols.  The handshaking protocols consist of three
   sub-protocols, namely the handshake protocol, the change cipher spec
   protocol and the alert protocol.  The handshake protocol allows the
   server and client to authenticate each other and to negotiate an
   encryption algorithm and cryptographic keys before the application
   protocol transmits or receives data.

> 
> The design of DTLS [...]
> 
>  
> 
> s/Since DTLS operates on top of an unreliable datagram transport a few
> enhancements to the TLS structure are, however necessary./However, since
> DTLS operates on top of an unreliable datagram transport, it must
> explicitly cope with the reliable and ordered delivery assumptions made
> by TLS./
> 
Fixed.

>  
> 
> s/Section 4.7 of RFC 5246 defines stream ciphers in TLS as follows.  In
> stream.../Section 4.7 of RFC 5246 defines stream ciphers in TLS as
> follows: in stream.../
> 
> 
Fixed.

Ciao
Hannes

---

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Fri, 6 Mar 2015 21:31:41 +0000

>Would this work for you as well?

Yes it will, thanks.