Re: [core] Question reg. draft-fossati-tls-iot-optimizations-00

"Fossati, Thomas (Nokia - GB)" <thomas.fossati@nokia.com> Wed, 02 November 2016 09:37 UTC

Return-Path: <thomas.fossati@nokia.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05334129A41 for <core@ietfa.amsl.com>; Wed, 2 Nov 2016 02:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 9ieumx4qEwz7 for <core@ietfa.amsl.com>; Wed, 2 Nov 2016 02:37:26 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18715129A37 for <core@ietf.org>; Wed, 2 Nov 2016 02:37:26 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id A7B73B143D02E; Wed, 2 Nov 2016 09:37:21 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA29bNGE016619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Nov 2016 09:37:23 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uA29YhSP024131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Nov 2016 10:37:22 +0100
Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.52]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Wed, 2 Nov 2016 10:34:57 +0100
From: "Fossati, Thomas (Nokia - GB)" <thomas.fossati@nokia.com>
To: "Hudalla Kai (INST/ESY1)" <Kai.Hudalla@bosch-si.com>, "core@ietf.org" <core@ietf.org>
Thread-Topic: [core] Question reg. draft-fossati-tls-iot-optimizations-00
Thread-Index: AQHSNOxftrDwnBm7nkS6PSjsWoQnzw==
Date: Wed, 02 Nov 2016 09:34:56 +0000
Message-ID: <D43F60A9.74AFB%thomas.fossati@alcatel-lucent.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.9.160926
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <B2C3B1E8C2FE5549B7A306FA59B5CF8F@exchange.lucent.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/5jf7gRq8g6K5taddvmwXU9C0YEE>
Subject: Re: [core] Question reg. draft-fossati-tls-iot-optimizations-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Nov 2016 09:37:28 -0000

Hi Kai, Achim (sorry for the late reply, I wasn't looking at the TLS list).

IIRC the idea came from Stephen (Farrell) in an attempt to add
privacy-preserving properties to the (potentially) long term identifier.

It's clearly a strawman and I'm happy to discuss its merits (in particular
the fact that when NAT rebinding happens without the client knowing it in
advance, the privacy of this is already gone) and impact in the IoT space
(in term of state that is kept on server side if handling multiple
connections at a time).

However, whatever the mechanism we come up with, I think privacy
preservation should be a goal, or at least something that is taken as a
first class criterion for selection.

Cheers, t


On 02/11/2016 07:29, "core on behalf of Hudalla Kai (INST/ESY1)"
<core-bounces@ietf.org on behalf of Kai.Hudalla@bosch-si.com> wrote:
>Hi list,
>
>I have attended last week's meeting of the T2T RG in Ludwigsburg where we
>had a
>vivid discussion around the problems of DTLS on mobile and other NATed
>networks
>where the device's IP address and/or port are expected to change once in
>a while.
>
>We quickly came to the conclusion that the CoAP spec will need to be
>changed in a
>way that removes the transport's addressing information from the
>Request/Response
>matching criteria when using DTLS.
>
>However, what alternative mechanism could be used instead?
>
>Section 4.2 of draft-fossati-tls-iot-optimizations-00 proposes to use a
>connection ID as part of the DTLS record structure. While I understand the
>usefulness of using a "long term identifier" for associating the session
>with the
>client, I do not really understand, how a "hash chain" could be put to
>use in
>this context to provide an improved level of privacy.
>
>Could someone (of the authors) comment on that?
> 
>-- 
>Mit freundlichen Grüßen / Best regards
>
>Kai Hudalla
>Chief Software Architect
>
>Bosch Software Innovations GmbH
>Schöneberger Ufer 89-91
>10785 Berlin
>GERMANY
>www.bosch-si.com
>
>Registered office: Berlin, Register court: Amtsgericht Charlottenburg,
>HRB 148411 B;
>Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>_______________________________________________
>core mailing list
>core@ietf.org
>https://www.ietf.org/mailman/listinfo/core