Re: [TLS] Attack description ... was RE: DTLS 1.3 AEAD additional data

[Achim Kraus <[e-mail]>]

Hi Martin,

 > So this depends on either concurrent use of the two CIDs,

with that and the "routing based on cid", I would raise the question, if
the usage of the cid turns into a swiss-army-knife?
Therefore it may get larger, and so it gets attractive,
to use it only on the first record, but leave it out on follow up records.
So, is that the idea? Use a large CID to include more information?

 > or moving a record from before a change in CID to after a change.

I'm still not common to DTLS 1.3.
With DTLS 1.2 a resumption- or full-handshake will result in a new
context. So for me moving the record will fail.

best regards
Achim

Am 24.04.20 um 12:09 schrieb Martin Thomson:
> Hi Hannes,
>
> Let me see if I can clarify then :)
>
> On Fri, Apr 24, 2020, at 18:31, Hannes Tschofenig wrote:
>>> Say that a connection spans two network paths.  CID A is used on path
>> A; CID B is used on path B.
>> I guess you are considering a scenario where a device, of the lifetime
>> of the communication with another peer, changes from CID A to CID B.
>> Is this correct?
>
> I don't think that DTLS really says what the CID is for, but this particular attack depends on being able to shift records from a datagram containing a record that has CID A to a datagram containing a record with CID B.  So this depends on either concurrent use of the two CIDs, or moving a record from before a change in CID to after a change.
>
> Imagine that you have record 1 and 2 in the same datagram, with record 1 having CID A and record 2 having no explicit CID (but for the same connection, as required).  Then record 3 is sent with CID B (maybe on a different path).  The attacker can remove record 2 from the first datagram and add it to the second.  If the attacker can determine whether record 2 was consumed, it can confirm that CID A and CID B are for the same connection.
>
>>> Let's assume that you need a connection ID to route (otherwise, why
>> bother), but that the first record in each datagram is all that is
>> needed for that purpose.
>> What do you mean by "route" here? The CID was primarily introduced to
>> allow the receiving party to correctly find the correct security
>> context to verify and decrypt the packet.
>
> by "route" I am trying to be generic.  In QUIC, the CID is used by cooperating middleboxes to select server instances.  But as you say, it is also used to identify which connection (and the right keys) to pick from potentially many choices, without necessarily using addressing information (which might have changed).  To me, that's all just routing, whether between boxes, or threads, or connections.
>
>>> If an endpoint sends a datagram on path A that contains two records where the second record omits the connection ID, then an attacker can strip that second record out and copy it into a datagram sent on path B.  With the current design, the receiver accepts that packet and maybe leaks some signal to the attacker that CID A and CID B really are the same connection.
>>
>> If you copy the record that does not contain the CID and send it to the
>> peer independently then with the current text in the spec the packet
>> will be dropped.
>
> Probably, yeah.  That's why you need to find a record with the other CID to pair it with.  Besides, the "attack" is trying to link CID A and CID B, and having the record consumed without linking to either doesn't tell the attacker much (except perhaps that the CID wasn't needed for routing purposes).
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>