Re: [TLS] Connection ID Draft

[yinxinxing <[e-mail]>]

1.       I mean that NewconnectionID message and the RequesConnectionID message should use the new record format (instead of standard DTLS1.2 record format). Besides, the CID in the record header shall not be the new CID.


2.       (c): Since the first two bits of 16-bit length variable is zero, we can use a  specifically-constructed CID like “11xxxx…” (or other proper format) to identify a CID packet.
(I have mentioned this in previous email and you gave some feedback:

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.
)


3.       For (d), I have some comments about its precondition. You see NAT device can reallocate the released port/IP address to client, which means the precondition doesn’t always hold.

发件人: Eric Rescorla [mailto:[e-mail]]
发送时间: 2017年10月26日 12:05
收件人: yinxinxing
抄送: [e-mail]
主题: Re: [TLS] Connection ID Draft



On Wed, Oct 25, 2017 at 8:02 PM, yinxinxing <[e-mail]<mailto:[e-mail]>> 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-mail]<mailto:[e-mail]>]
发送时间: 2017年10月23日 20:13
收件人: yinxinxing
抄送: [e-mail]<mailto:[e-mail]>
主题: Re: [TLS] Connection ID Draft



On Mon, Oct 23, 2017 at 12:53 AM, yinxinxing <[e-mail]<mailto:[e-mail]>> 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-mail]<mailto:[e-mail]>]
发送时间: 2017年10月13日 21:00
收件人: yinxinxing
抄送: [e-mail]<mailto:[e-mail]>
主题: Re: [TLS] Connection ID Draft



On Fri, Oct 13, 2017 at 1:11 AM, yinxinxing <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>] 代表 Eric Rescorla
发送时间: 2017年10月13日 7:14
收件人: [e-mail]<mailto:[e-mail]>
主题: [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