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

[Simon Bernard <[e-mail]>]

I think identity is not checked at DTLS layer, but at the CoAP Layer. 
For RPK we can use the public key.

I mean the DTLS layer ensure encryption and authentication.
At CoAP level, you will get your decrypted data and the DTLS identity, 
up to you to ensure you talk to the right peer.
For example, if you add the LWM2M Layer where peer are identified by 
registration endpoint , you need to associate this registration endpoint 
to a DTLS identity (the public key for RPK).


Le 02/11/2016 à 17:25, Kraus Achim (INST/ESY1) a écrit :
> Hi,
>
>> IMHO, using the DTLS identity seems the better choice. (PSK identity for PSK, public key for RPK, CN for certificate).
> For PSK identity, and CN certificate they may be a choice.
>
> But for RPK, can you explain, how the identity is checked on DTLS layer?
>
> 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: Simon Bernard [mailto:[e-mail]]
> Gesendet: Mittwoch, 2. November 2016 17:09
> An: Kraus Achim (INST/ESY1) <[e-mail]>; [e-mail]
> Betreff: Re: [core] Question reg. draft-fossati-tls-iot-optimizations-00
>
> 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:[e-mail]] Im Auftrag von Fossati,
>> Thomas (Nokia - GB)
>> Gesendet: Mittwoch, 2. November 2016 10:35
>> An: Hudalla Kai (INST/ESY1) <[e-mail]>; [e-mail]
>> 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)"
>> <[e-mail] on behalf of [e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/core
>> _______________________________________________
>> core mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/core
>>
>> _______________________________________________
>> core mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/core
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core