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

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

Hi Thomas,

thanks! That's makes the intention of the hash chain much clearer!
 
If it's just intended, that the client uses a fixed sized list/set of CIDs and may repeats a CID or chose a other 
CID from the list (as long as the CID is not acknowledged), I don't see my "robustness" issue.
    
(I thought,  that the list of CIDs is "almost infinite" and on incrementing the record sequence number the
next H() is called to ensure, that every record has its own CID. With that, it's evil, if the hashs are only 
calculated for e.g. 8 records ahead, but, caused by whatever, more messages then 8 are dropped. )

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: Fossati, Thomas (Nokia - GB) [mailto:[e-mail]] 
Gesendet: Mittwoch, 2. November 2016 15:11
An: Kraus Achim (INST/ESY1) <[e-mail]>; [e-mail]
Betreff: Re: [ALU] Re: [core] Question reg. draft-fossati-tls-iot-optimizations-00

Hi Achim,

On 02/11/2016 10:33, "core on behalf of Kraus Achim (INST/ESY1)"
<[e-mail] on behalf of [e-mail]> wrote:
>Though draft-fossati-tls-iot-optimizations-00 was published in the tls 
>wg, I posted my question there.

Yes, you made the correct assumption, my fault.

>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),

The idea is that, during handshake, client and server negotiate the CID extension.

As usual with TLS, client proposes the extension, in this case indicating the desired length of the hash chain (i.e., the number of different CIDs) to use.

If server supports the CID extension, it replies with the effective length of the hash chain ("L"), which shall be equal or less than what the client proposed.

The shared secret output by the handshake is used to produce an ordered list of "L" CIDs.  I don't think it really matters that the production happens via a hash chain, or any other mechanism, as long as:
1. The produced list is the same on both sides of the wire (in values, length and cardinality); 2. An external observer doesn't learn anything about the next CID(s) by passively looking at the CID(s) that have circulated so far.

(I guess a "for i in 1..L: CID[i] = HMAC(shared_secret, string(i))" would fit the purpose.)

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

I agree.  That's why I think "client proposes, server chooses" is the right way to negotiate it.

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

I'm not sure I understand your concern here.

The idea is that the client has it's own "CID shift" policy (e.g., based on time, or number of packets exchanged, NAT rebinding awareness, etc.) and will decide unilaterally when to move to the next CID in chain, until the chain is exhausted.  The server will mirror the last CID received.  In this scheme, packet loss has no impact as long as client keeps alive CIDs that have been shifted but not yet "acknowledged" by the server on the back channel.  (This is true if both sides keep the chain in place for as long as the security association is active.)

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

Sorry, I'm not sure I completely understand the advantage of this scheme.

Cheers, thanks,
t