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 protected]] 
发送时间: 2017年10月13日 23:41
收件人: yinxinxing; Eric Rescorla; [email protected]
主题: Re: [TLS] Connection ID Draft

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

Reply via email to