Re: [TLS] 答复: Connection ID Draft

On Fri, Oct 13, 2017 at 7:36 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> 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.
>

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.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
>> >
>>
>
>