Re: Security of coalesced packets

[Mikkel Fahnøe Jørgensen <[e-mail]>]

Would you mind elaborating what the additional attack vector by
allowing on-path devices to embed octets introduces?

It is widely known that there are is broad logging of traffic at major
distribution points, typically controlled by various state actors or
related agencies. Hence, if you can inject a signal early on the path, you
can collect it later for correlation.

Additionally script kiddies might be able to inject traffic monitoring at
corporate traffic gateways so work at home employees could ferry payload
via their NAT router to somewhere inside the firewall, and vice versa. Thus
you could download massive amounts of sensitive data undetected such as
stealing operating system source code or the latest release of Shawn the
Sheep extended DVD edition.



On 12 July 2018 at 09.30.01, Kazuho Oku ([e-mail]) wrote:

2018-07-12 15:44 GMT+09:00 Mikkel Fahnøe Jørgensen <[e-mail]>:
> An issues was recently closed regarding what to do when UDP datagrams
> contain coalesced QUIC packets where some are not understood. The
> requirement is that the connection ID must match in all QUIC packets but
> otherwise packets that do not verify should be buffered or ignored
> independently of other packets.
>
> https://github.com/quicwg/base-drafts/issues/1319#issuecomment-404403569
>
> There are good reasons to coalesce because it makes the early handshake
much
> more efficient and there are good reasons to allow packets that do not
> verify because they may relate to key material not yet available.
>
> However, considering the effort spend in trying to avoid linkability, it
> appears to me that third-parties can easily inject tracking information
in
> ordinary QUIC packets using the coalescing mechanism.

Would you mind elaborating what the additional attack vector by
allowing on-path devices to embed octets introduces?

Current design just throws away the junk. It does not affect the state
of the connection. So while it is possible for an on-path device to
alter the packet, the device cannot see if it reached the peer.

To me the situation seems indifferent to on-path devices sending
additional packet using the 5-tuple when it sees a packet belonging to
the QUIC connection.

>
> Even if the connection ID must match, it is easy to just copy the
connection
> ID from the primary packet and insert a global tracking cookie near the
> source of the packet, such as in a compromised home NAT router.
>
> Tracking can also be done with ordinary tunnelling but that is sometimes
> desirable inside infrastructure, and far more difficult to manipulate
> outside such boundaries - e.g. a compromised NAT router would not be able
to
> do it.
>
> These issues could be avoided by only permitting certain early packets to
> coalesce.
>
> I do not have the overview of other possible valid uses of coalescing
such
> as during migration or rekeying.
>
>
> Kind Regards,
> Mikkel Fahnøe Jørgensen
>



-- 
Kazuho Oku