I would like to focus on one of the points raised below: > 3. We have a practical usecase in IoT. The IOT device, like > intelligent water meter, sends one message per day, and goes to sleep. > It wakes up in the second day and sends a message and then goes to > sleep. If it always (or for a long time) use the same CID, there may be > a risk of tracing IOT device or the owner of this device. Therefore, it > is important to recommend user to update CID once it finishes sending > message. For the CID in DTLS1.2, this becomes worse.
The user is typically not doing anything. Without this CID extension you would send a full exchange or use session resumption. This would allow someone in the middle to see the handshake. In DTLS/TLS 1.2 this would reveal the client certificate. With DTLS 1.3 and this extension you would hide the certificate and you could echange new CIDs and switch between them every day. The source IP address will most likely still reveal the subscriber (if you consider some cooperation with the ISP). So, you actually get pretty good privacy properties with DTLS 1.3 & CID (unless some of the data center folks destroy it again with their fancy extensions). With DTLS 1.2 there is only a performance benefit but the privacy properties remain the same IMHO. Ciao Hannes > > > > Regards, > > Yin Xinxing > > > > *发件人:*TLS [mailto:[email protected]] *代表 *Eric Rescorla > *发送时间:*2017年10月13日7:14 > *收件人:*[email protected] > *主题:*[TLS] Connection ID Draft > > > > Hi folks, > > > > I have just posted a first cut at a connection ID draft. > > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 > > > > Comments welcome. > > > > -Ekr > > > > > > > > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
