[TLS] 答复: Connection ID Draft

yinxinxing <yinxinxing@huawei.com> Sat, 14 October 2017 02:00 UTC

Return-Path: <yinxinxing@huawei.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567041320CF for <tls@ietfa.amsl.com>; Fri, 13 Oct 2017 19:00:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHuuvab-vapJ for <tls@ietfa.amsl.com>; Fri, 13 Oct 2017 19:00:15 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C101241F3 for <tls@ietf.org>; Fri, 13 Oct 2017 19:00:14 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXR67195; Sat, 14 Oct 2017 02:00:13 +0000 (GMT)
Received: from DGGEMI406-HUB.china.huawei.com (10.3.17.144) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 14 Oct 2017 03:00:12 +0100
Received: from DGGEMI508-MBS.china.huawei.com ([169.254.3.228]) by dggemi406-hub.china.huawei.com ([10.3.17.144]) with mapi id 14.03.0301.000; Sat, 14 Oct 2017 10:00:03 +0800
From: yinxinxing <yinxinxing@huawei.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Eric Rescorla <ekr@rtfm.com>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Connection ID Draft
Thread-Index: AQHTQ6/jzwfbCTuMF0C4wkI09eDpT6LhQz+AgAAFfACAAAWEgIABSPsg
Date: Sat, 14 Oct 2017 02:00:02 +0000
Message-ID: <DBDF9AE44733284D808F0E585E1919022C7AAC27@dggemi508-mbs.china.huawei.com>
References: <CABcZeBPXB6cOSztzDHtKSWUCJrgET+9cF_rAiiE8CYCUSY_uLA@mail.gmail.com> <574d133f-0531-2206-c7d3-825ebaffacdd@cs.tcd.ie> <CABcZeBM_xUadFDnAK-FLGjqciDOLGoePv8xhSFkmBYS5nooXxQ@mail.gmail.com> <765bb5b0-2129-9ea8-2c51-b6b4163748e8@cs.tcd.ie>
In-Reply-To: <765bb5b0-2129-9ea8-2c51-b6b4163748e8@cs.tcd.ie>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.184.225.248]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.59E16FAD.004F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.228, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 4be5258770b575f21713cf51650b7029
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Gru8Z27j9UECcCTWhw15Opi_-xQ>
Subject: [TLS] 答复: Connection ID Draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Oct 2017 02:00:17 -0000

I agree with Stephen. It is essential to ensure the new connection ID couldn't be linked to the old one to avoid tracking risk.

However, it is some sort of implementation issues, and there are more ways to do that(not only hash method). Maybe we can at least give suggestions or warning in the draft.

Regards,
Yin Xinxing 

-----邮件原件-----
发件人: TLS [mailto:tls-bounces@ietf.org] 代表 Stephen Farrell
发送时间: 2017年10月13日 22:17
收件人: Eric Rescorla
抄送: tls@ietf.org
主题: Re: [TLS] Connection ID Draft


Hiya,

On 13/10/17 14:56, Eric Rescorla wrote:
> I've seen a number of designs like these, but in general they have 
> quite poor scaling properties. Can you describe the precise design you 
> have in mind so that we can analyze it.

Sure, I can try...

What I'm suggesting is that we define a way that a TLS node can change the connection ID to a new value that is hard to link to the old, as a function that can be used when the implementation chooses to use it.

I'm not currently arguing that the ids should be changed for each packet. E.g. if a node is able to detect that the 5-tuple has just changed, it could use this then. If a node sends one packet per day over say an nb-IoT network where it might have a different IP address each time (not that we know how nb-IoT will operate, so I'm guessing:-) then it might make sense to do this for every packet.

I assume ids are initialised in some reasonable way.

To change an id, pick a value foo that depends on the TLS session, e.g. like an extractor, and that is not visible to the network. Then set next-id to H(foo||prev-id) or some similar construct.

Receivers can store a set of ids calculated when the session is established. I'd guess storing two (current and next) might be a sensible thing to do.

The inefficiently compared to simply incrementing the id value is to add another column to the lookup table I guess. I don't know if that's a big scaling deal or not.

Cheers,
S.