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

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

Thomas, thanks for explaining. Further comments below ...

On Mi, 2016-11-02 at 17:08 +0000, Fossati, Thomas (Nokia - GB) wrote:
> Hi Kai,
> 
> On 02/11/2016 15:49, "core on behalf of Hudalla Kai (INST/ESY1)"
> <[e-mail] on behalf of [e-mail]> wrote:
> > 
> > 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.
> Yes, but then the receiver would have to do a bit of acrobatics to compute
> all the future CIDs of the active sessions if the received CID is not
> found in the hash table.  I think pre computation has its advantages in
> this case -- the server controls the CIDs chain length and could adapt the
> proposed value based on both its overall capacity and current load.
> 
You are absolutely right, I missed out on that problem.

> > 
> > > 
> > > > 
> > > > 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.
> I think the hash should be truncated to avoid adding too much overhead on
> the (possibly constrained) channel. Could you please elaborate a bit more
> on the security issue you are seeing here?  (I can see potential issues
> with lookup collisions (i.e. functional) if the CID is chosen from a small
> space, but the security impact is not very clear to me.)
> 
I agree that the "uniqueness" property of the hashes will probably be reduced
very significantly and this will probably cause a much greater problem (from a
functional perspective). Using only truncated hashes might, however, make the
hash function itself less secure, i.e. it might be easier for an attacker to
determine the next hash if he only needs to make sure that the first six bytes
are correct. Again, I am not a security expert but I can imagine that the
guarantees an HMAC function makes regarding distribution and irreversibility are
somewhat dependent on the length as well ...


> > 
> > In any case, I like the idea very much :-) What do we need to do in order
> > to
> > bring this forward?
> If there is interest (as it seems) we could try and draft it in a slightly
> less concise way :-)
> 
> The original plan with Hannes was to also prototype it in his (1.3)
> implementation (mbedtls).  If you have another TLS stack that would be
> really great.
> 
Yes, I would like to incorporate such a mechanism into the Californium Java CoAP
stack.