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

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

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.

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

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

Cheers, thanks,
t