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.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
