Hi Ekr, Thanks for your effort. The draft looks good. A few comments are listed below.
1. Based on the draft, for either DTLS1.2 or 1.3, server can’t differentiate whether the packet from client is a “connection ID” packet or a standard DTLS 1.2/1.3 packet. (I saw Thomas Fossati and Nikos also introduced this problem) Maybe we can add a new “ContentType” in the DTLS record format to help server identify the “connection ID” packet. In addition, you see the length of the record payload is limited by 2^14-1, this means the first two bits of “length” is zero. We could utilize this feature and set the first two bits or more bits of CID being one, e.g., 1111….(but the CID must be put between sequence number and length). When server finds 1111 after sequence number, it knows this is a “connection ID” packet. However, I don’t know whether it is proper to use such magic number. In my view, adding new contenttype may be a choice. 2. For DTLS 1.2, there is no NewConnectionID and RequestConnectionID message. DTLS 1.2 server and client also has the requirement to request for a new CID, and at present, many products still use DTLS1.2 and I believe it will continue to be used for a long time even if TLS/DTLS1.3 is published. My point is that we need a corresponding method for updating CID for DTLS1.2 too. I don’t quite understand the following sentences “In DTLS 1.2, connection ids are exchanged at the beginning of the DTLS session only. There is no dedicated "connection id update" message that allows new connection ids to be established mid-session, because DTLS 1.2 in general does not allow post-handshake messages that do not themselves begin other handshakes.” Besides, for CID in DTLS1.3, I think the corresponding responding messages of NewConnectionID and RequestConnectionID are also needed to ensure that the peer has received CID. 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. 4. The generation of CID should be more concrete. For example, using random number or a counter? Regards, Yin Xinxing 发件人: TLS [mailto:tls-boun...@ietf.org] 代表 Eric Rescorla 发送时间: 2017年10月13日 7:14 收件人: tls@ietf.org 主题: [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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
