Re: [TLS] Connection ID Draft

[Eric Rescorla <[e-mail]>]

On Wed, Oct 25, 2017 at 8:02 PM, yinxinxing <[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]]
> *发送时间:* 2017年10月23日 20:13
> *收件人:* yinxinxing
> *抄送:* [e-mail]
> *主题:* Re: [TLS] Connection ID Draft
>
>
>
>
>
>
>
> On Mon, Oct 23, 2017 at 12:53 AM, yinxinxing <[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]]
> *发送时间**:* 2017年10月13日 21:00
> *收件人**:* yinxinxing
> *抄送**:* [e-mail]
> *主题**:* Re: [TLS] Connection ID Draft
>
>
>
>
>
>
>
> On Fri, Oct 13, 2017 at 1:11 AM, yinxinxing <[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]] *代表* Eric Rescorla
> *发送时间**:* 2017年10月13日 7:14
> *收件人**:* [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
>
>
>
>
>
>
>
>
>
>
>