On Fri, Oct 13, 2017 at 7:28 PM, yinxinxing <yinxinx...@huawei.com> 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 > Regards, > Yin Xinxing > > -----邮件原件----- > 发件人: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] > 发送时间: 2017年10月13日 23:41 > 收件人: yinxinxing; Eric Rescorla; tls@ietf.org > 主题: 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-boun...@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 > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
