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

["Hudalla Kai (INST/ESY1)" <[e-mail]>]

On Mi, 2016-11-02 at 14:10 +0000, Fossati, Thomas (Nokia - GB) wrote:
> 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.)
> 
Assuming that "shared_secret" is derived from the pre-master or master secret and
 "string(i)" means "get the ASCII representation of integer i's digits", then
this function would have the additional advantage of not requiring both sides to
"pre-compute" the whole list of CIDs in advance but instead being able to compute
the next CID ad-hoc when it is needed, wouldn't it? The client and server would
only need to keep track of counter i in this case.

> > 
> > 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.)
> 
My only concern would be that not using the full HMAC values as the CIDs but
instead only using the, say, first 6 bytes would actually make the CIDs
vulnerable again. However, I am not a security expert and have no clue whether
this is a problem or not.

In any case, I like the idea very much :-) What do we need to do in order to
bring this forward?