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

Super, Sebastien!

I'll help as much as I can. I have a conflict on Thursday but will try to show up as much as I can.

Take care,

Pascal

-----Original Message-----
From: core [mailto:core-bounces@ietf.org] On Behalf Of Simon Bernard
Sent: mercredi 2 novembre 2016 18:22
To: Fossati, Thomas (Nokia - GB) <thomas.fossati@nokia.com>; Kraus Achim (INST/ESY1) <Achim.Kraus@bosch-si.com>; core@ietf.org
Subject: Re: [core] [ALU] Re: Question reg. draft-fossati-tls-iot-optimizations-00

With TLS 1.2 we currently don't have this tracking aspect consideration 
? Identity is sent in clear, by sniffing the network you could know who 
send to who. This seems to me like another issue/feature.

Currently TLS don't protect you from tracking or provide you any 
anonymity : "The primary goal of the TLS protocol is to provide privacy 
and data integrity between two communicating applications." (+ 
authentication)

As a wiseman tell to me : "one step at a time !".

(ConnectionID will have a lifetime less or equals than the session 
lifetime, this means 24h maximum. This limit the tracking activity based 
on connectionID to 24h)

Le 02/11/2016 à 17:52, Fossati, Thomas (Nokia - GB) a écrit :
> Hi Simon,
>
> On 02/11/2016 16:08, "core on behalf of Simon Bernard"
> <core-bounces@ietf.org on behalf of contact@simonbernard.eu> wrote:
>> Hi all,
>>
>>     I'm not sure to understand the point here.
>>     *   The "draft-fossati-tls-iot-optimizations-00" says "The privacy
>> issue associated with the use of a long-term identifier
>>     must be taken into consideration."
>>     *   Thomas says "I think privacy preservation should be a goal".
>>     I would like to understand which privacy concern we would like to
>> achieve exactly ? With TLS we have end to end encryption. You want to
>> add a kind of  anonymity ? or maybe protect ourself from connectionid
>> spoofing ?
> The issue is that something like CID will make tracking a device activity
> across different transports very easy.  (Personally, I think NAT rebinding
> is a bit different because it usually happens without client awareness,
> and therefore already exposes correlation information to a possible
> tracker.)
>
> In any case, if we make this an extension of the general TLS protocol we
> need to make sure we design it in a way that a) is fit for the purpose
> from a functional and security perspective, and b) takes into
> consideration the tracking aspects for clients that want to have finer
> control on their privacy.
>
>
>>     From my point of view, the connection id is just a way to replace
>> the IP address by a connection identifier for use-cases where IP address
>> is not fixed. So we have the same security level with connection id than
>> fixed IP. We are maybe a bit more exposed to spoofing as connectionid
>> spoofing is probably more simple than UDP IP address spoofing, but not
>> so much. I mean connectionid is just another way to retrieve security
>> context needed to decrypt Application Data.
> ISTM that if CID has enough randomness and is integrity-protected, then
> spoofing is not an issue (or it is less an issue than security context
> lookup based on a fully tamperable 5-tuple).  But certainly this is a
> dimension to explore further (e.g. depending on the way CID is
> synchronised on the two sides, there might be opportunities for an
> attacker that can selectively drop packets from the network to do
> different things, I guess).
>
> Cheers, t
>

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core