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:tls-bounces@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
> 