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

From: "Hudalla Kai (INST/ESY1)" <[email-masked]>
Date: Wed, 2 Nov 2016 07:29:22 +0000

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

---

From: "Kraus Achim (INST/ESY1)" <[email-masked]>
Date: Wed, 2 Nov 2016 08:27:34 +0000

Hi Kai,

I posted a related question also on the tls mailing list.

https://www.ietf.org/mail-archive/web/tls/current/msg21737.html

"Dear Authors,

draft-fossati-tls-iot-optimizations-00 mentions in 4.2, page 5, a hash chain (Lampert, "Password Authentication with Insecure Communication"). 

Would it be possible, to get more details about that approach?

In my opinion, DTLS needs a connection id, the record is usually secured by the MAC. 
So the hash chain providing a "password" seems for me to rely on a "identity", for which the "password" should be verified. 
But that identity is missing and the verification is done with the MAC.

Use this in reverse, I could think of something as:

connection hash := H ^ record.sequence_number (connection id)
    
So with an incoming record {sequence_number, connection hash} you may look up, if "connection ids" hashed
"sequence_number" times results in the provided "connection hash" and then you may verify, if one of the
candidates will verify with the MAC.  Even with defining a "sequence number window" to exclude "faraway"
sessions, I'm not sure,  how such an approach would scale for a large number of session.

So could you please provide your ideas about that hash chain?"

So hopefully we get some clarification on that issue, even if the main focus in tls right now seems to be tls 1.3.

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:[email-masked]] Im Auftrag von Hudalla Kai (INST/ESY1)
Gesendet: Mittwoch, 2. November 2016 08:29
An: [email-masked]
Betreff: [core] Question reg. draft-fossati-tls-iot-optimizations-00

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.

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.

Kai Hudalla
Chief Software Architect

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn _______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core