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

["Fossati, Thomas (Nokia - GB)" <[e-mail]>]

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