Re: Security of coalesced packets

[Kazuho Oku <[e-mail]>]

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