On Wed, Oct 25, 2017 at 8:02 PM, yinxinxing <yinxinx...@huawei.com> wrote:
> Hi Ekr, > > > > Sorry for the delay. I don’t quite understand “The way that this > mechanism works is that it either replaces all of them or supplements the > set.” I see the new CID is encrypted in the post-handshake message and > transferred to the peer. So, the record header of this message needs to > contain the “old” CID. > Yes. I don't understand what your question is. When you send a new CID, you can either label it as cid_immediate or cid_spare. "immediate" means "stop using all the other CIDs you have and "spare" means "this is a CID you can use in addition to the others you have. > Besides, I have summarized the ways of distinguishing the CID packet and > standard packet that people have discussed in the mailing list: > > a) Adding new ContentType. > > b) Adding new version. (As you replied, since 1.3 is going to > remove version field in the record header, so this choice may not be > proper.) > > c) Using specifically-constructed CID. (I saw you replied that it > would be a way for DTLS 1.2. But for 1.3, you want a different way.) > > d) By comparing the 5-tuple. Martin made this. (If I understand > right) His idea is that first check the 5-tuple of the packet, if there is > a match, then use the corresponding key. If there is no match, then treat > the packet as a CID packet and find the CID in the packet according to the > new format. But, the precondition for well working is that the 5-tuple of > the CID packet will not be successfully matched in the receiver's 5-tuple > table. > > > > For the above choices, what do you think? Or do you have any other good > solution to be updated in the draft? > I think we should do neither (a) nor (b). I don't really understand (c) but I think (d) is fine, though not the only technique implementors could use. -Ekr > > > Regards, > > Yin Xinxing > > > > *发件人:* Eric Rescorla [mailto:e...@rtfm.com] > *发送时间:* 2017年10月23日 20:13 > *收件人:* yinxinxing > *抄送:* tls@ietf.org > *主题:* Re: [TLS] Connection ID Draft > > > > > > > > On Mon, Oct 23, 2017 at 12:53 AM, yinxinxing <yinxinx...@huawei.com> > wrote: > > Hi Ekr, > > > > For the post-handshake messages in the draft, I have some comments. > > > > 1. When one peer sends NewconnectionID message to the other, it > uses a newly defined handshake type. This new CID is attached in the > payload of the record message. But there must be some information for the > receiver to know which CID is going to be updated. I mean that when sending > new CID through the NewConnectionID message, the record header should > include the “old” CID, so that the receiver knows which one to replace. > > The way that this mechanism works is that it either replaces all of them > or supplements the set. I'm not sure that this is the right dynamic, but > I'd first want to see some worked through cases. > > > > 2. In the draft, is the new CID encrypted? I suggest that the new > CID (for the first time sending) can be encrypted to make sure that an > attacker can not associate a new CID with an old CID. Let’s consider a case > where an attacker wants to track an IOT device. If the newly generated CID > is not encrypted when updating, the attacker can associate the new CID with > the old one. Then, when the peer sends message with the new CID later, the > attacker knows this packet is sent from the victim. If we encrypt the new > CID when updating, this tracking problem can be avoided. > > > > TLS 1.3 post-handshake messages are always encrypted. > > > > Another comment is about symmetrical CID. > > 1. Consider a client sends a normal CID (CID length is not zero, > named C-CID) to server, but the server doesn’t wants to use client’s CID > and sends a CID generated by the server (named S-CID) to the client. > > No. The CID is for the client's benefit, so why would this be useful? > > > > At the same time, client needs to know server has ignored C-CID (which > means the downlink application message from the server will not include > C-CID), and client will use S-CID in its application message. Will the > draft cover this scenario? > > No. > > > > -Ekr > > > > > > Yin Xinxing > > > > *发件人**:* Eric Rescorla [mailto:e...@rtfm.com] > *发送时间**:* 2017年10月13日 21:00 > *收件人**:* yinxinxing > *抄送**:* tls@ietf.org > *主题**:* Re: [TLS] Connection ID Draft > > > > > > > > On Fri, Oct 13, 2017 at 1:11 AM, yinxinxing <yinxinx...@huawei.com> wrote: > > 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. > > > > As I said to Nikos, for DTLS 1.2, you can use a specially-constructed CID > that would not be a valid length field. This can actually just have the > leading bit set. As we're revising the DTLS 1.3 record format, we would > need to do something different for that. > > > > 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. > > In general, the WG is working on TLS 1.3, not TLS 1.2, so I'm not really > that excited about putting a lot of effort into enhancing TLS 1.2. The > basic extension works fine for them, but if they want to change CIDs, then > they should adopt DTLS 1.3. > > > > 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.” > > > > The only post-handshake messages allowed in DTLS 1.2 are ClientHello and > HelloRequest. > > > > 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. > > > > No, you use the ACK for these (https://tools.ietf.org/html/ > draft-ietf-tls-dtls13-01#section-7). This is one reason why there is not > a straightforward port to DTLS 1.2 for these messages. > > > > 4. The generation of CID should be more concrete. For example, > using random number or a counter? > > I explicitly did not want to do that, because there are a lot of valid > ways to generate CID. This is also what we did in QUIC. > > > > -Ekr > > > > > > > > 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
