Re: [TLS] 答复: Connection ID Draft

On Fri, Oct 13, 2017 at 7:28 PM, yinxinxing <yinxinxing@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.tschofenig@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-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
> >
>