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

["Kraus Achim (INST/ESY1)" <[e-mail]>]

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