MIME-Version: 1.0
In-Reply-To: <CAN1APdfrjbZvvJj33taJpYCc2utTuHwZx8O6_um-nB7OLpFx5Q@mail.gmail.com>
References: <CAN1APdfrjbZvvJj33taJpYCc2utTuHwZx8O6_um-nB7OLpFx5Q@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Thu, 12 Jul 2018 16:30:00 +0900
Message-ID: <CANatvzyrfvjnZ3Y4FKiW0fRVahmArXyaJk9gt2NrZPgaOX-WaQ@mail.gmail.com>
Subject: Re: Security of coalesced packets
To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/eJxFrXKen0IoC-XUJgYjYDoCzI8>
Precedence: list

2018-07-12 15:44 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmai=
l.com>:
> 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 m=
uch
> 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 i=
n
> 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 connect=
ion
> 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 suc=
h
> as during migration or rekeying.
>
>
> Kind Regards,
> Mikkel Fahn=C3=B8e J=C3=B8rgensen
>



--=20
Kazuho Oku