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

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Wed, 2 Nov 2016 14:10:53 +0000

Hi Achim,

On 02/11/2016 10:33, "core on behalf of Kraus Achim (INST/ESY1)"
<[email-masked] on behalf of [email-masked]> 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

---

From: "Kraus Achim (INST/ESY1)" <[email-masked]>
Date: Wed, 2 Nov 2016 15:06:10 +0000

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

Hi Achim,

>according your answer, I guess Stephen (Farrell) may be the right 
>person, to give an answer.
>

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

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

>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.
>
>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) .
>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.
>mapping to check the MAC and ignores the message, when the check fails.
>require such a connection id, so it would just be used for "rarely" 
>communicating client periods.
>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).

Cheers, thanks,
t

---

From: "Hudalla Kai (INST/ESY1)" <[email-masked]>
Date: Wed, 2 Nov 2016 15:49:20 +0000

> (I guess a "for i in 1..L: CID[i] = HMAC(shared_secret, string(i))" would
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.

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

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Wed, 2 Nov 2016 17:08:53 +0000

Hi Kai,

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

>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

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

---

From: "Hudalla Kai (INST/ESY1)" <[email-masked]>
Date: Thu, 3 Nov 2016 08:21:32 +0000

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

> proposed value based on both its overall capacity and current load.
You are absolutely right, I missed out on that problem.

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

> implementation (mbedtls).  If you have another TLS stack that would be
Yes, I would like to incorporate such a mechanism into the Californium Java CoAP
stack.

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Thu, 3 Nov 2016 10:26:30 +0000

Hi Kai,

On 03/11/2016 08:21, "core on behalf of Hudalla Kai (INST/ESY1)"
<[email-masked] on behalf of
>somewhat dependent on the length as well ...

Assuming the attacker doesn't know the shared key, the worst that can
happen is that she is able to forge a valid CID which has not been used
yet.

However, given HMAC's properties (i.e., it is a PRF under the sole
assumption that its compression function is a PRF), this should only be
possible by luck -- with 2^(-n) chances, where n is the length of the
truncated HMAC.

I've not done any serious analysis, but it seems to me that CID forgery
would result in a failure decrypting the forged record and possibly a
de-synchronisation of the CID?  That seems less scary than a server having
to worry about collisions in its lookup table.

>Yes, I would like to incorporate such a mechanism into the Californium

Super!  I'll try and draft a proposal that can be implemented ASAP.

Cheers, t

---

From: Simon Bernard <[email-masked]>
Date: Thu, 3 Nov 2016 12:24:04 +0100

Hi Fossati,

    I would like to insist again about this tracking concern. I see the 
point and I think this is a good point to try to achieve this purpose at 
long term in TLS. But we are going into an IPv6 world with fixed IP, so 
correlating packet will be easier. I know there is RFC to limit this 
kind of tracking issue on IPv6 (https://tools.ietf.org/html/rfc4941) and 
like session the default lifetime is 1day. So from my point of view all 
of this hash chain seems a bit overkill. CID will live as long as 
sessions live, so we limit correlation to 24h, as if we live in an IPv6 
world.

     FMPOV the short term issue is to be able to use DTLS 1.2 in a 
changing IP address environment, mainly the NAT issue. This is the 
problem we faced today. An extension to do that will be welcomed :). I 
hope this kind of hash chain will not be mandatory when using CIDs.

     Another concern, using hash chain will not allow load balancing 
based on CID which could be very usefull for cluster architecture.

     (Californium implementation currently aims DTLS 1.2)

Simon

Le 03/11/2016 à 11:26, Fossati, Thomas (Nokia - GB) a écrit :
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Thu, 3 Nov 2016 12:10:55 +0000

Hi Simon,

>hope this kind of hash chain will not be mandatory when using CIDs.

It is not mandatory.  Server can always say: L=1 to all clients that want
to negotiate the CID extension.

Cheers, t

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

---

From: "Kraus Achim (INST/ESY1)" <[email-masked]>
Date: Thu, 3 Nov 2016 14:20:34 +0000

Hi,

> It is not mandatory.  Server can always say: L=1 to all clients that want to negotiate the CID extension.

Wed, 2 Nov 2016 14:10:53 +0000:
> back channel.

With L := 1, 
What does "the chain is exhausted" mean?
What is the idea of "not yet "acknowledged" by the server on the back channel?

Achim Kraus

-----Ursprüngliche Nachricht-----
Von: core [mailto:[email-masked]] Im Auftrag von Fossati, Thomas (Nokia - GB)
Gesendet: Donnerstag, 3. November 2016 13:11
An: Simon Bernard <[email-masked]>; Fossati, Thomas (Nokia - GB) <[email-masked]>; Hudalla Kai (INST/ESY1) <[email-masked]>; [email-masked]
Betreff: Re: [core] [ALU] Re: [ALU] Re: Question reg.draft-fossati-tls-iot-optimizations-00

Hi Simon,

On 03/11/2016 11:24, "Simon Bernard" <[email-masked]> wrote:
>point and I think this is a good point to try to achieve this purpose 
>at long term in TLS. But we are going into an IPv6 world with fixed IP, 
>so correlating packet will be easier. I know there is RFC to limit this 
>kind of tracking issue on IPv6 (https://tools.ietf.org/html/rfc4941) 
>and like session the default lifetime is 1day. So from my point of view 
>all of this hash chain seems a bit overkill. CID will live as long as 

It is not mandatory.  Server can always say: L=1 to all clients that want to negotiate the CID extension.

Cheers, t

>>>> 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 ...
>> happen is that she is able to forge a valid CID which has not been 
>> used yet.
>>
>> assumption that its compression function is a PRF), this should only 
>> be possible by luck -- with 2^(-n) chances, where n is the length of 
>> the truncated HMAC.
>>
>>
>> I've not done any serious analysis, but it seems to me that CID 
>>forgery  would result in a failure decrypting the forged record and 
>>possibly a  de-synchronisation of the CID?  That seems less scary than 
>>a server having  to worry about collisions in its lookup table.
>>
>>>> If there is interest (as it seems) we could try and draft it in a 
>>>> slightly less concise way :-)
>>>>
>>>> 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.

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Thu, 3 Nov 2016 14:43:48 +0000

Hi Achim,

>What does "the chain is exhausted" mean?

The semantics should be the same as L:=n when there have been already n-1
shifts: i.e., there are no more CIDs to try and you are stuck with this.

>What is the idea of "not yet "acknowledged" by the server on the back

Since there is no forward shift possible the server acknowledgement is not
relevant because you can always assume that the other party is aligned --
independently of packet loss.

Cheers, t

---

From: "Hudalla Kai (INST/ESY1)" <[email-masked]>
Date: Mon, 7 Nov 2016 09:06:25 +0000

> possible by luck -- with 2^(-n) chances, where n is the length of the
I agree that this is the "lower boundary" for the probability to "guess" the
right CID. However, my concern is that not all values of all digits of the HMAC
are evenly distributed which might further reduce the number of digits an
attacker is required to "guess" correctly.
> to worry about collisions in its lookup table.
I agree that a forged CID in conjunction with an unknown master secret should not
be a problem. However, the same reasoning applies to the probabilty of a CID
collision in the server's "hash table". Do you know anyone who has more insight
into an HMAC's properties regarding these issues and who could shed some light on
it?

> Super!  I'll try and draft a proposal that can be implemented ASAP.
That would be great :-)

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Mon, 7 Nov 2016 10:36:56 +0000

Hi Kai,

>into an HMAC's properties regarding these issues and who could shed some

HMAC behaves like a PRF, therefore the birthday paradox applies.  I have
crunched some numbers below about the probability to get a collision with
n-bit CID and varying number of concurrent sessions.  The takeaway is that
choosing an appropriate CID size is not going to be trivial, and that a
32-bit CID might be too small for a lot of practical use cases...

Cheers, t

Using 32-bits CID
#sessions | collision probability
====================================================
10        |  1.16415320717e-08, or about 1 in 85,899,347
100       |  1.16415254059e-06, or about 1 in 858,994
1000      |  0.000116408545826, or about 1 in 8,590
10000     |  0.011574031737, or about 1 in 86
100000    |  0.687813095694, or about 1 in 1
1000000   |  1.0, or about 1 in 1

Using 40-bits CID
#sessions | collision probability
====================================================
10        |  4.54747350886e-11, or about 1 in 21,990,232,556
100       |  4.54747350886e-09, or about 1 in 219,902,326
1000      |  4.54747247525e-07, or about 1 in 2,199,024
10000     |  4.54737011285e-05, or about 1 in 21,991
100000    |  0.00453714940666, or about 1 in 220
1000000   |  0.365391719084, or about 1 in 3

Using 48-bits CID
#sessions | collision probability
====================================================
10        |  1.7763568394e-13, or about 1 in 5,629,499,534,213
100       |  1.7763568394e-11, or about 1 in 56,294,995,342
1000      |  1.7763568394e-09, or about 1 in 562,949,953
10000     |  1.77635668175e-07, or about 1 in 5,629,500
100000    |  1.77634106228e-05, or about 1 in 56,295
1000000   |  0.00177478005137, or about 1 in 563

Using 56-bits CID
#sessions | collision probability
====================================================
10        |  6.66133814775e-16, or about 1 in 1,501,199,875,790,165
100       |  6.93889390391e-14, or about 1 in 14,411,518,807,586
1000      |  6.93889390391e-12, or about 1 in 144,115,188,076
10000     |  6.93889390391e-10, or about 1 in 1,441,151,881
100000    |  6.93889365966e-08, or about 1 in 14,411,519
1000000   |  6.93886982983e-06, or about 1 in 144,116

Using 64-bits CID
#sessions | collision probability
====================================================
10        |  so small that python choked :-)
100       |  2.22044604925e-16, or about 1 in 4,503,599,627,370,496
1000      |  2.70894418009e-14, or about 1 in 36,914,751,044,020
10000     |  2.71049849232e-12, or about 1 in 368,935,825,950
100000    |  2.71050515366e-10, or about 1 in 3,689,349,193
1000000   |  2.71050539791e-08, or about 1 in 36,893,489

---

From: "Hudalla Kai (INST/ESY1)" <[email-masked]>
Date: Mon, 7 Nov 2016 17:11:15 +0000

> #sessions | collision probability

I am not sure if I fully understand what you actually have computed. My guess is
that you have computed the probabilities using a "birthday problem" approximation
formula replacing #sessions for the number of people 2^(CID length) for the
number of days per year, right?

In any case, the interesting question is what we actually consider a "collision".
When the server creates the CID it needs to check whether the CID itself and the
corresponding hash chain collides with any of the already existing CIDs, or
doesn't it? Is it sufficient to verify that the CID itself is not already taken?
If not, the check can become quite expensive, I guess ...

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 7 Nov 2016 20:12:29 +0100

The current discussion confuses me a lot.
Apparently, I’m missing some context.
So I’ll try to state what I have understood so far.

Current state:

When a node receives a DTLS packet, it uses the four-tuple (2x transport address, each consisting of IP address and port number) to find the security association (“connection”) inside which the packet is to be interpreted.

Problem:

The four-tuple changes.

Solution:

When that is the case, the receiver could simply try all security assocations it has until one matches (i.e., the MAC works out).

Problem:

This is expensive if the receiver has many security associations.
(The expense also leads to an easy DOS attack, so it MUST be avoided.)

Solution:

Add a hint to the packet, so the number of security associations to be searched by a receiver is reduced to a trivial amount.

As with classical (computer science) hash tables, a collision is not a problem; it just slightly reduces the efficiency.

If the hint is reasonably probabilistically well-distributed, something like 16 (or maybe 24) bits should suffice except for the really large servers with more than several million active security associations.

What am I missing?

(Once we have agreement or clarification on what I have said, we can go back to discussion unsinkable progressions of these hints.)

Grüße, Carsten

---

From: "Hudalla Kai (INST/ESY1)" <[email-masked]>
Date: Tue, 8 Nov 2016 07:47:36 +0000

On Mon, 2016-11-07 at 20:12 +0100, Carsten Bormann wrote:
> When a node receives a DTLS packet, it uses the four-tuple (2x transport
> address, each consisting of IP address and port number) to find the security
> association (“connection”) inside which the packet is to be interpreted.
> 
> Problem:
> 
> The four-tuple changes.
> 
correct

> Solution:
> 
> When that is the case, the receiver could simply try all security assocations
> it has until one matches (i.e., the MAC works out).
> 
> Problem:
> 
> Add a hint to the packet, so the number of security associations to be searched
> by a receiver is reduced to a trivial amount.
> 
What you say is true and I think that such a trial-and-error approach will be
suitable to determine the correct association.

> If the hint is reasonably probabilistically well-distributed, something like 16
> (or maybe 24) bits should suffice except for the really large servers with more
> than several million active security associations.
> 
> What am I missing?
> 
I guess the intersting problem would be how to reduce the "trial-and-error"
approach to only those cases where the four-tupel has actually changed and being
able to do a "direct" lookup in most of the cases (maybe including the four-tupel 
information).

> (Once we have agreement or clarification on what I have said, we can go back to
> discussion unsinkable progressions of these hints.)
> 
> Grüße, Carsten
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Nov 2016 09:06:52 +0100

Good morning, Kai,

> On 8 Nov 2016, at 08:47, Hudalla Kai (INST/ESY1) <[email-masked]> wrote:
> 

I would expect implementations to do exactly that: Use the four-tuple as the first hint (and maybe check any other hint included in the packet).  Only if that fails to bring up a security association, try to find one using the other, address-independent but less precise hint only.

The way of handling a failure in the first case is interesting: Given that the other hint has collisions, there is an unlikely case that everything matches (because the four-tuple has been in use by another security association before — yes, there are collisions on the four-tuple, too — and the other hint happens to match because of a collision) and the MAC still fails.  So we probably should recommend making a secondary lookup based on the other hint even in this case of failing to MAC.  (The DOS potential does not increase appreciably, I think.)

So the algorithm would be: Try all security associations that match the other hint, but try those (depending on how you discard address hints, there could even be multiple!) that match the addresses first.  If the MAC goes through and there is no replay, adjust the address hint*).

Grüße, Carsten

*) I haven’t entirely thought through the security implications of that recommendation, but given that the address is only a weak hint now, this should be limited to enabling an attacker to cause additional work.

---

From: "Kraus Achim (INST/ESY1)" <[email-masked]>
Date: Tue, 8 Nov 2016 08:23:51 +0000

Hi Carsten,

> If the hint is reasonably probabilistically well-distributed, something like 16 (or maybe 24) bits should suffice except for the really large
> servers with more than several million active security associations.

> What am I missing?

From Fossati, Thomas (Nokia - GB), Wed, 2 Nov 2016 14:10:53 +0000
> The shared secret output by the handshake is used to produce an ordered list of "L" CIDs.

So the number of clients must be multiplied with the number of CIDs per connection. 
And the number of CIDs defines, how "anonymous" the connections are over the time.
So I'm not sure, if the collisions will not affect the server performance significantly.

Achim Kraus

-----Ursprüngliche Nachricht-----
Von: core [mailto:[email-masked]] Im Auftrag von Carsten Bormann
Gesendet: Montag, 7. November 2016 20:12
An: Hudalla Kai (INST/ESY1) <[email-masked]>
Cc: [email-masked]
Betreff: Re: [core] [ALU] Re: [ALU] Re: Question reg.draft-fossati-tls-iot-optimizations-00

Current state:

Problem:

The four-tuple changes.

Solution:

Problem:

Solution:

What am I missing?

Grüße, Carsten

---

From: "Hudalla Kai (INST/ESY1)" <[email-masked]>
Date: Tue, 8 Nov 2016 08:26:44 +0000

Hi Carsten,

On Tue, 2016-11-08 at 09:06 +0100, Carsten Bormann wrote:
> I would expect implementations to do exactly that: Use the four-tuple as the
> first hint (and maybe check any other hint included in the packet).  Only if
> that fails to bring up a security association, try to find one using the other,
> address-independent but less precise hint only.
> 
Yes, I came up with the same approach.

> The way of handling a failure in the first case is interesting: Given that the
> other hint has collisions, there is an unlikely case that everything matches
> (because the four-tuple has been in use by another security association before
> — yes, there are collisions on the four-tuple, too — and the other hint happens
> to match because of a collision) and the MAC still fails.  So we probably
> should recommend making a secondary lookup based on the other hint even in this
> case of failing to MAC.  (The DOS potential does not increase appreciably, I
> think.)
> 
> So the algorithm would be: Try all security associations that match the other
> hint, but try those (depending on how you discard address hints, there could
> even be multiple!) that match the addresses first.  If the MAC goes through and
> there is no replay, adjust the address hint*).
> 
Sounds like a good "working thesis". I am a little concerned, though, that this
will have a major impact on the way Californium's DTLS stack i implemented today
:-(

@Thomas: WDYT? Is this worth finding its way into the "next level" draft?

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Tue, 8 Nov 2016 10:04:37 +0000

Hi Carsten,

On 07/11/2016 19:12, "Carsten Bormann" <[email-masked]> wrote:
>Apparently, I¹m missing some context.
>So I¹ll try to state what I have understood so far.
>
>Current state:
>
>address, each consisting of IP address and port number) to find the
>security association (³connection²) inside which the packet is to be
>interpreted.
>
>Problem:
>
>The four-tuple changes.
>
>Solution:
>
>When that is the case, the receiver could simply try all security
>assocations it has until one matches (i.e., the MAC works out).
>
>Problem:
>
>Add a hint to the packet, so the number of security associations to be
>searched by a receiver is reduced to a trivial amount.
>
>As with classical (computer science) hash tables, a collision is not a
>problem; it just slightly reduces the efficiency.
>
>If the hint is reasonably probabilistically well-distributed, something
>like 16 (or maybe 24) bits should suffice except for the really large

I think accepting the possibility of collisions might have tricky edge
cases.  One that comes to my mind is you have 2 (or more) security
associations with same CID.  One of them goes through NAT rebind and
afterwards sends a packet.  The packet is corrupted (either at the source
because of an implementation error, or in the network -- maliciously or
not).  The lookup strategy that you describe would go through the matching
sessions and fail decryption for all of them.  It must then send an alert
indicating the failure and terminate the session.  Which one will it
choose?

In any case, this is an issue only for the privacy preserving CID.  If we
also allow a server chosen CID as in our WIP proposal [1], than the
problem simply doesn't exist.

Cheers, t

[1] 
https://raw.githubusercontent.com/thomas-fossati/ietf/master/dtls-iot-ext/d
raft-fossati-tls-iot-extensions.txt

>
>(Once we have agreement or clarification on what I have said, we can go
>back to discussion unsinkable progressions of these hints.)
>
>Grüße, Carsten
>
>

---

From: Simon Bernard <[email-masked]>
Date: Tue, 8 Nov 2016 11:44:29 +0100

Kai, I think in Californium we should start without hash chain for CID. 
We will avoid this kind of problem as Thomas said in this last mail.

I think we should not go in massive refactoring just to implement hash 
chain, knowning that without this we have the same privacy that when we 
use IPv6. (see 
https://mailarchive.ietf.org/arch/msg/core/QVWn6VzEZW0fmdeCsj3bLbf1KLc )

---

From: "Hudalla Kai (INST/ESY1)" <[email-masked]>
Date: Tue, 8 Nov 2016 14:08:48 +0000

> We will avoid this kind of problem as Thomas said in this last mail.
Are you proposing to always use L=1 in Californium, i.e. use a "degenerated" hash
chain of length 1?

> > > > On 8 Nov 2016, at 08:47, Hudalla Kai (INST/ESY1) <[email-masked]
> > > > m>
> > > > wrote:
> > > > 
> > > > approach to only those cases where the four-tupel has actually changed
> > > > and
> > > > being
> > > > able to do a "direct" lookup in most of the cases (maybe including the
> > > > four-
> > > > tupel
> > > > information).
> > >

---

From: Simon Bernard <[email-masked]>
Date: Tue, 8 Nov 2016 15:17:51 +0100

Always ? I don't know.

At short term, yes that's what I proposed. The way you said it looks 
like a HACK but if I well understand Thomas using hashchain for "strong" 
privacy is an option.

---

From: "Hudalla Kai (INST/ESY1)" <[email-masked]>
Date: Tue, 8 Nov 2016 16:54:01 +0000

> like a HACK but if I well understand Thomas using hashchain for "strong" 
I didn't want to imply that this was a "hack". I just wanted to make sure that I
correctly understood what you meant :-)

It's fine for me to start with L=1 in Californium. It should already solve our
pressing issues around NAT timeouts ...

> > > > > I would expect implementations to do exactly that: Use the four-tuple
> > > > > as
> > > > > the
> > > > > first hint (and maybe check any other hint included in the
> > > > > packet).  Only
> > > > > if
> > > > > that fails to bring up a security association, try to find one using
> > > > > the
> > > > > other,
> > > > > The way of handling a failure in the first case is interesting: Given
> > > > > that
> > > > > the
> > > > > should recommend making a secondary lookup based on the other hint even
> > > > > in
> > > > > this
> > > > > case of failing to MAC.  (The DOS potential does not increase
> > > > > appreciably,
> > > > > I
> > > > > think.)
> > > > > 
> > > > > even be multiple!) that match the addresses first.  If the MAC goes
> > > > > through
> > > > > and
> > > > Sounds like a good "working thesis". I am a little concerned, though,
> > > > that
> > > > this
> > > > will have a major impact on the way Californium's DTLS stack i
> > > > implemented
> > > > today
> > > > :-(
> > > >