Subject: Re: [TLS] Connection ID Draft

From: yinxinxing <[email-masked]>
Date: Fri, 13 Oct 2017 08:11:37 +0000

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:[email-masked]] 代表 Eric Rescorla
发送时间: 2017年10月13日 7:14
收件人: [email-masked]
主题: [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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 13 Oct 2017 05:59:38 -0700

On Fri, Oct 13, 2017 at 1:11 AM, yinxinxing <[email-masked]> wrote:

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

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

> 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:[email-masked]] *代表 *Eric Rescorla
> *发送时间:* 2017年10月13日 7:14
> *收件人:* [email-masked]
> *主题:* [TLS] Connection ID Draft
>
>
>
> Hi folks,
>
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Oct 2017 17:40:46 +0200

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-masked]] *代表 *Eric Rescorla
> *发送时间:*2017年10月13日7:14
> *收件人:[email-masked]
> *主题:*[TLS] Connection ID Draft
> 
>  
> 
> Hi folks,
> 
>  
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: yinxinxing <[email-masked]>
Date: Sat, 14 Oct 2017 02:28:33 +0000

Hi Hannes,

"exchange new CIDs and switch between them every day" may not be a good choice for power constrained IOT devices. From the point of saving battery, it is better to transfer the new CID to the other peer in the application responding message in passing, instead of sending an independent updating CID message. 

In addition, like what Stephen mentioned, it is essential to avoid linkability between new CID and old CID. This is not covered in this draft.

For 1.2, in this draft, there is no NewConnectionID and RequestConnectionID message, how can the CID be updated. This is what I mean "worse".

Regards,
Yin Xinxing

-----邮件原件-----
发件人: Hannes Tschofenig [mailto:[email-masked]] 
发送时间: 2017年10月13日 23:41
收件人: yinxinxing; Eric Rescorla; [email-masked]
主题: Re: [TLS] Connection ID Draft

I would like to focus on one of the points raised below:
> 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.

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 13 Oct 2017 19:36:42 -0700

On Fri, Oct 13, 2017 at 7:28 PM, yinxinxing <[email-masked]> wrote:

> Hi Hannes,
>
> "exchange new CIDs and switch between them every day" may not be a good
> choice for power constrained IOT devices. From the point of saving battery,
> it is better to transfer the new CID to the other peer in the application
> responding message in passing, instead of sending an independent updating
> CID message.
>

Well, that's obviously something you could do but it's not part of TLS,
though of course you could use the connection ID in TLS.

>
> In addition, like what Stephen mentioned, it is essential to avoid
> linkability between new CID and old CID. This is not covered in this draft.
>

New security considerations text welcome.

For 1.2, in this draft, there is no NewConnectionID and RequestConnectionID
> message, how can the CID be updated. This is what I mean "worse".
>

Yes. As I said, I'm not really trying to fix TLS 1.2, though I'm happy to
have the extension used both places.

-Ekr

> address will most likely still reveal the subscriber (if you consider some
> cooperation with the ISP).
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 13 Oct 2017 19:39:18 -0700

On Fri, Oct 13, 2017 at 7:36 PM, Eric Rescorla <[email-masked]> wrote:

> For 1.2, in this draft, there is no NewConnectionID and
>> RequestConnectionID message, how can the CID be updated. This is what I
>> mean "worse".
>>
>

With that said, it's not like it's impossible; it's just work. But the WG
policy has been to focus on TLS 1.3 and not on retrofitting TLS 1.3
improvements to 1.2.

-Ekr

---

From: yinxinxing <[email-masked]>
Date: Sat, 14 Oct 2017 02:41:20 +0000

Thanks Ekr.

For “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.”, the key point of describing the generation of CID is to avoid linkability between new CID and old ones, although there are lots of valid ways.

Regards,
Yin Xinxing

发件人: Eric Rescorla [mailto:[email-masked]]
发送时间: 2017年10月13日 21:00
收件人: yinxinxing
抄送: [email-masked]
主题: Re: [TLS] Connection ID Draft

On Fri, Oct 13, 2017 at 1:11 AM, yinxinxing <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ekr,

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.

The only post-handshake messages allowed in DTLS 1.2 are ClientHello and HelloRequest.

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:[email-masked]<mailto:[email-masked]>] 代表 Eric Rescorla
发送时间: 2017年10月13日 7:14
收件人: [email-masked]<mailto:[email-masked]>
主题: [TLS] Connection ID Draft

Hi folks,

Comments welcome.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 13 Oct 2017 19:46:44 -0700

On Fri, Oct 13, 2017 at 7:41 PM, yinxinxing <[email-masked]> wrote:

> Thanks Ekr.
>
>
>
> For “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.”, the key
> point of describing the generation of CID is to avoid linkability between
> new CID and old ones, although there are lots of valid ways.
>

I don't really get what you're proposing here. As I said, there are a lot
of ways to generate connection IDs and it's not helpful to prescribe one.
We might be able to require that it not be possible to distinguish whether
two conn IDs are from the same connection with probability > \epsilon, but
even that is notrivial if (for instance) they have a generation ID. So I'd
prefer to describe the issue in the security considerations and leave the
details up to implementations.

-Ekr

>
> Regards,
>
> Yin Xinxing
>
>
>
> *发件人:* Eric Rescorla [mailto:[email-masked]]
> *发送时间:* 2017年10月13日 21:00
> *收件人:* yinxinxing
> *抄送:* [email-masked]
> *主题:* Re: [TLS] Connection ID Draft
>
>
>
>
>
>
>
> 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.
>
> 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.
>
>
>
> 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
>
>
>

---

From: yinxinxing <[email-masked]>
Date: Sat, 14 Oct 2017 03:09:57 +0000

(I mean that we give some warning and suggestion on the linkability, although there are lots of valid ways.)

I miss reading the security consideration part, now,  I have saw the warning of linkability. No problem now.

Yin Xinxing

发件人: Eric Rescorla [mailto:[email-masked]]
发送时间: 2017年10月14日 10:47
收件人: yinxinxing
抄送: [email-masked]
主题: Re: 答复: [TLS] Connection ID Draft

On Fri, Oct 13, 2017 at 7:41 PM, yinxinxing <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Ekr.

I don't really get what you're proposing here. As I said, there are a lot of ways to generate connection IDs and it's not helpful to prescribe one. We might be able to require that it not be possible to distinguish whether two conn IDs are from the same connection with probability > \epsilon, but even that is notrivial if (for instance) they have a generation ID. So I'd prefer to describe the issue in the security considerations and leave the details up to implementations.

-Ekr

Regards,
Yin Xinxing

发件人: Eric Rescorla [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2017年10月13日 21:00
收件人: yinxinxing
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [TLS] Connection ID Draft

-Ekr

Regards,
Yin Xinxing

Hi folks,

Comments welcome.

-Ekr