On Fri, Oct 13, 2017 at 7:36 PM, Eric Rescorla <e...@rtfm.com> wrote:
> > > 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. > 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 > > -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
