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

Simon Bernard <contact@simonbernard.eu> Wed, 02 November 2016 16:08 UTC

Return-Path: <contact@simonbernard.eu>
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 103E21294C5 for <core@ietfa.amsl.com>; Wed, 2 Nov 2016 09:08:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 gDvu4XjNydo2 for <core@ietfa.amsl.com>; Wed, 2 Nov 2016 09:08:40 -0700 (PDT)
Received: from 9.mo5.mail-out.ovh.net (9.mo5.mail-out.ovh.net [178.32.96.204]) (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 4C737129462 for <core@ietf.org>; Wed, 2 Nov 2016 09:08:40 -0700 (PDT)
Received: from player692.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo5.mail-out.ovh.net (Postfix) with ESMTP id 84A973B533 for <core@ietf.org>; Wed, 2 Nov 2016 17:08:37 +0100 (CET)
Received: from [10.41.51.97] (130.163-14-84.ripe.coltfrance.com [84.14.163.130]) (Authenticated sender: contact@simonbernard.eu) by player692.ha.ovh.net (Postfix) with ESMTPSA id 68D506000BA; Wed, 2 Nov 2016 17:08:35 +0100 (CET)
To: "Kraus Achim (INST/ESY1)" <Achim.Kraus@bosch-si.com>, "core@ietf.org" <core@ietf.org>
References: <D43F60A9.74AFB%thomas.fossati@alcatel-lucent.com> <BC36447FF5C62E46BEF3F124D3C1E8925E1F5F6B@imbpw2exd01.bosch-si.com>
From: Simon Bernard <contact@simonbernard.eu>
Message-ID: <607f8720-8e86-90f6-83fd-299939c298ae@simonbernard.eu>
Date: Wed, 02 Nov 2016 17:08:34 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0
MIME-Version: 1.0
In-Reply-To: <BC36447FF5C62E46BEF3F124D3C1E8925E1F5F6B@imbpw2exd01.bosch-si.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 1118300086453745831
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelvddrkeefgdekfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Jd55hFQqLBInzdYr1NYa5ZlRzIg>
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 16:08:43 -0000

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

    About CoAP Observation behind a NAT using DTLS, I think we have 
several issues.

    *  First one: define a long term identifier for CoAP. At CoAP level 
users would like to know from which or to which they send data, nothing 
more. IMHO, using the DTLS identity seems the better choice. (PSK 
identity for PSK, public key for RPK, CN for certificate). From my point 
of view there is no need to strongly link this to the DTLS session as it 
was currently the case in CoAP spec [1][2]. Nobody seems really able to 
explain this choice and this doesn't work behind NAT. With this 
constraint, it can also be tempting to increase the session lifetime to 
be able to increase the observation lifetime which seems not to be a 
good idea as security level.
    *  Second point: be able to use DTLS with dynamic IP address (e.g. 
NAT) without the need to redo full handshake or resume handshake. The 
"connectionId" proposed in this draft seems to resolve the issue. It 
could also really help to do load balancing using this connectionid 
instead of IP address in a cluster environment.

Simon

[1]https://tools.ietf.org/html/rfc7641#section-7 (All notifications 
resulting from a GET request with an Observe Option MUST be returned 
within the same epoch of the same connection as the request.)
[2]https://tools.ietf.org/html/rfc7252#section-9.1.1 (The DTLS session 
MUST be the same, and the epoch MUST be the same.)

Le 02/11/2016 à 11:33, Kraus Achim (INST/ESY1) a écrit :

> Hi Thomas,
>
> thanks for your answer.
> Though draft-fossati-tls-iot-optimizations-00 was published in the tls wg, I posted my question there.
>
> Currently I'm simply not sure, if I understood the approach right, but according your answer,
> I guess Stephen (Farrell) may be the right person, to give an answer.
>
> With my understanding (see mail in tls, https://www.ietf.org/mail-archive/web/tls/current/msg21737.html),
>
> I see following issues with the hash chain:
> The scaling/performance depends on the "hash chain window" used to related the record to the dtls connection.
> As larger the window, the more I'm in doubt, if that scales.
> The robustness for clients, when we lose more packets then we assume in the window.
> As smaller the window, the more I'm in doubt, if it's robust enough.
>
> There may be an escape using the "record sequence number" in a more sophistic way
> (e.g. using H(record.sequence_numer | connection_id) would help to skip faster over
> lost messages, but still with a large number of clients/connections, I don't see how this
> scales). But right now I guess, we need more guidance, how it was intended.
>
> Therefore I could think also of an alternative solution with an "connection id ticket" system.
> The DTLS server sends after the handshake a ticket with the "encrypted connection id".
> The DTLS client decrypts that ticket into the connection id and, if the client later
> didn't receive a message for a certain period of time (e.g. 20s), it adds that connection id to
> the records until it receives a new ticket (encrypted new connection id) .
> When the client receives a new ticket, then it could send the messages again without the
> connection id until it doesn't receive messages for the certain period of time, after which
> the new ticket is used.
> The DTLS server only accepts records with that "decrypted" connection id, if the MAC check is passed.
> It the adjusts the address/port and emits a new ticket. If the DTLS server receives "invalid"
> (or no longer valid) connection ids, it uses the current address/port mapping to check the MAC and ignores
> the message, when the check fails.
> The advantage of that would be, that "high frequent" traffic doesn't require such a connection id,
> so it would just be used for "rarely" communicating client periods. Indicate with an extension, it would
> leave the current DTLS implementation unchanged as long as they are proper working right now and
> just offer an extension to those, wo would require it because of either to frequent address changes or
> to limited bandwidth (for dtls resumes/handshakes).
> And the server only needs those tickets, if the client and the server agrees on using them.
>
> Mit freundlichen Grüßen / Best regards
>
> Achim Kraus
>
> Bosch Software Innovations GmbH
> Communications (INST/ESY1)
> Stuttgarter Straße 130
> 71332 Waiblingen
> GERMANY
> www.bosch-si.de
> www.blog.bosch-si.com
>
> Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
> Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: core [mailto:core-bounces@ietf.org] Im Auftrag von Fossati, Thomas (Nokia - GB)
> Gesendet: Mittwoch, 2. November 2016 10:35
> An: Hudalla Kai (INST/ESY1) <Kai.Hudalla@bosch-si.com>; core@ietf.org
> Betreff: Re: [core] Question reg. draft-fossati-tls-iot-optimizations-00
>
> 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
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core