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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
