Subject: [Uta] draft-yang-uta-dtls13-for-iot

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 10 Dec 2018 13:34:45 +0000

Hi Yang,

Valery pointed me to your draft, which I had failed to notice. Thanks for the write-up.

I read through it since it appears to have some relevance to draft-tschofenig-uta-tls13-profile-01 and here are a few comments:

- IoT Services Scenarios and Devices

   o  Low mobility, high communication throughput applications, such as
      wireless surveillance cameras.  This kind of equipment moves in
      the limited location, the communication frequency is high, the
      bandwidth is hug, but the processing capability of this kind is
      low.  Reducing resources consumption for the security functions
      shall obviously cut down the hardware cost.

My impression is that surveillance cameras are high-computing devices since the video processing requires some cycles. For this reason they are often equipped with A-class processors and run a full-fletched OS, like Linux.

4.1.  Shorten Message Size of Handshaking

   In TLS 1.3, the size of handshaking message can be very large.  If
   TCP is used, it will not have a significant impact, but when
   transmission of large messages on the UDP, it means fragmentation,
   loss, retransmission, disordering and waiting, which shall contribute
   to the long latency for DTLS handshake process.

Fragmentation will always happen when the data to transmitted is larger than the Path MTU.
This can happen for application data as well as the DTLS/TLS handshake itself.

For application data this may happen when retrieving diagnostic/log data, streaming video data (as mentioned in your example above), or when sending a firmware update.

TLS and DTLS deal with fragmentation; in the TLS case great fragmentation support is provided by TCP and in case of DTLS it is built into the DTLS protocol itself. In most cases fragmentation of handshake message in DTLS/TLS is rather unlikely when run over IPv6 when ECC-based crypto with a flat certificate hierarchy is used. Of course, you can shoot yourself in the foot by either using RSA, or long certificate chains. There are some radio technologies that have a very small frame size but they require an adaptation layer, like 6lowpan, which provides the fragmentation & reassembly support on the link.

In a nutshell, fragmentation is a problem when done at the IP layer. Hence, my recommendation is to provide fragmentation at a different layer.

 This effect is more
   significant when the device communication traffic rate is low and the
   network coverage is poor.  Simplifying handshaking message size shall
   reduce the probability of fragmentation and fragmentation.  The
   observations may include:

   o  Under the precondition that security level is not decreased, the
      number of fields in the agreement is reduced and the value of the
      field is shortened.

Could you indicate what fields you believe should be omitted?

   o  Reduce the X.509 certificate fields and omit these unnecessary
      optional fields.  Commonly, the size of the certificate is about
      1K bytes, which always cause the message length to exceed MTU
      (1500).

ECC certificates are smaller and hence we recommend their use in the DTLS/TLS 1.2 profiles RFC.
You can also use raw public keys, if you don't require the other fields that are found in an X.509 certificate

1500 bytes is, btw, the MTU size for Ethernet.

4.2.  Problems Introduced by NAT

   Because of the large number of IoT devices, NAT is used in most IoT
   networks.  The problems introduced by NAT include:

   o  Cookie mismatch issues.  Because Client-IP is a input for HMAC of
      cookie value, when NAT is used, the device and server side have
      different client-IP, for high-speed mobile devices, due to the
      frequent device hand-over, the IP address changes shall lead to
      cookie mismatch.

The IP address will not change during the initial handshake;

ClientHello ---->
                    <---- HRR (cookie)
ClientHello ----->
(cookie)

   o  Keepalive costs a lot of resources, especially on low-traffic
      devices, appropriate mechanisms to balance NAT aging and
      maintaining secure channels is needed.

This is indeed a problem with NATs but so far all standardization efforts to dynamically configure the lifetime of NAT and firewall state have failed.

4.3.  Long-time Dormancy Devices

   Long-time dormant devices such as Watt-hour meter and water meters,
   because of the huge number devices with each have low communication
   frequency, greatly increase the burden in storing PSK in network side
   and device side.  The storage of PSK also increases the risk of PSK
   leakage.  If DTLS 1.3 session initiation process is used each time, a
   large number of interactions will occur, and the net service traffic
   is much less than the TLS protocol overhead.  We need to consider
   improving the DTLS mechanism for such devices.

Could you explain the burden in storing the PSK in the network and the device side a bit more?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.