Subject: Re: [WAS RE: New Version Notification for draft-kuhn-quic-0rtt-bdp-07.txt] Discussion on security

From: Ian Swett <[email-masked]>
Date: Mon, 9 Nov 2020 01:58:38 -0500

On Thu, Oct 29, 2020 at 8:47 PM Kazuho Oku <[email-masked]> wrote:

> Hi, Kuhn, Martin,
>
> What Martin wrote down is correct. Just two minor comments below.
>
> 2020年10月30日(金) 8:06 Martin Thomson <[email-masked]>:
>
>> I think that Kazuho was saying something else.  That is, there is no need
>> for a protocol here*.  If a server was able to send at X previously, it can
>> "remember" that by packing some extra information into NEW_TOKEN (or the
>> session ticket, but again I agree with Kazuho that NEW_TOKEN is more
>> appropriate).
>>
>> The usual caveats around the stability of network capacity over time
>> apply, which is why there might be some value in a document explaining how
>> not to do this.  For instance, just because you managed 1Gbps last Tuesday
>> at 1am, it doesn't mean that the same capacity will be available next
>> Thursday at 8pm.  But the idea that you might be able to do something
>> better than starting at a default congestion window isn't crazy.
>>
>> * Where a protocol might add value is not in storing values, but
>> constraining their use.  If a client successfully hits 1Gbps and wants to
>> send 0-RTT at nearly 1Gbps when it resumes, the server might want to be
>> able to provide some constraints.
>>
>
> Yes. theoretically, it is true that we need a protocol for constraining
> the send rate during the connection establishment phase. Though in case of
> QUIC v1, I'd assume that endpoints can (and will) use the transport
> parameters (e.g., initial_max_data) for that purpose.
>
> So far, to me it seems that the only case where a protocol extension makes
> sense is the use case that Matt brought up: sending server's view of the
> connection for letting clients decide what to request.
>

Agreed.  And if an application wanted to do that, I think it might be more
sensible to use an application specific mechanism, such as the HTTP header
proposed in: https://tools.ietf.org/html/draft-ohanlon-transport-info-header

>
>
>> On Fri, Oct 30, 2020, at 01:33, Kuhn Nicolas wrote:
>> >
>> > There were comments on the security aspects of the approach.
>> >
>> >
>> >
>> > Christian Huitema:
>> >
>> > I am glad that we agree. Now, we have an issue regarding security.
>> > Nicolas Kuhn and his coauthors have pursued a design in which the
>> > server sends an encrypted blob to the client,
>> >
>> > and then client echoes it in the new connection. This is largely based
>> > on concerns about potential attacks. Suppose the client said "I
>> > received at 1Gbps last time", when in fact
>> >
>> > it can only absorb 10 Mbps. Some bad stuff might well be happening
>> > along the way. But then, Matt is looking at passing statistics from
>> > server to client, so the client can debug issues,
>> >
>> > display statistics in the app, and potentially also reuse the
>> > statistics to inform server that the last connection had an RTT of 600
>> > ms and a data-rate of 100 Mbps, and maybe we should
>> >
>> > shortcut initial congestion control in order to gain lots of time. How
>> > do we reconcile these multiple goals?
>> >
>> >
>> >
>> > Kazuho Oku:
>> >
>> > Loss recovery and CC states are properties maintained by an endpoint.
>> > The peer should not be given the right to change them (e.g., CWND,
>> > RTT).
>> >
>> > Servers might offload the state to the client, but that state has to be
>> > encrypted and integrity-protected. NEW_TOKEN tokens cover this purpose.
>> >
>> >
>> >
>> > [NK] Indeed. Depending on how the 0-RTT extension is set up, the client
>> > may not be able to tune the values or the server may remember the
>> > values for cross-checking the information. We can rely on the transport
>> > parameter integrity protection already described in 7.4.1:
>> >
>> > *The server can remember these transport parameters, or store an*
>> >
>> > *integrity-protected copy of the values in the ticket and recover the*
>> >
>> > *information when accepting 0-RTT data.*
>> >
>> >
>> >
>> >
>> >
>> > Nicolas and Emile
>> >
>> >
>> >
>> > *De :* Ian Swett <[email-masked]>
>> > *Envoyé :* mardi 27 octobre 2020 14:39
>> > *À :* Kazuho Oku <[email-masked]>
>> > *Cc :* Christian Huitema <[email-masked]>; Kuhn Nicolas
>> > <[email-masked]>; IETF QUIC WG <[email-masked]>; Matt Joras
>> > <[email-masked]>; Lucas Pardue <[email-masked]>
>> > *Objet :* Re: New Version Notification for
>> > draft-kuhn-quic-0rtt-bdp-07.txt
>> >
>> >
>> >
>> > I agree with most of the points made by Kazuho and Christian.
>> >
>> >
>> >
>> > In particular, I think relying on information the client repeats back
>> > to the server which is not encrypted by the server is potentially quite
>> > dangerous.  Even with that, there's real potential for abuse,
>> > particularly when combined with 0-RTT, so if we're going to document
>> > something, I believe we need a lot of MUST NOTs to prevent that abuse.
>> > Using the same token across many connections seems particularly
>> > concerning.
>> >
>> >
>> >
>> > On Mon, Oct 26, 2020 at 10:30 PM Kazuho Oku <[email-masked]>
>> wrote:
>> >
>> > >
>> >
>> > >
>> >
>> > > 2020年10月27日(火) 11:14 Christian Huitema <[email-masked]>:
>> >
>> > >>
>> >
>> > >> On 10/26/2020 6:20 PM, Lucas Pardue wrote:
>> >
>> > >>>
>> >
>> > >>> On Tue, 27 Oct 2020, 01:12 Matt Joras, <[email-masked]>
>> wrote:
>> >
>> > >>>> Indeed, but as much as I love HTTP it's not the only protocol we
>> have on top of QUIC. A consistency argument can also be made for having a
>> connection-level metric tied to a connection-level semantic (i.e. a QUIC
>> frame) rather than the transactional-level semantic (HTTP header).
>> >
>> > >>>
>> >
>> > >>> I agree! A QUIC-level frame could be the most appropriate thing in
>> this case. I think this will be an interesting space for innovation. And
>> let's not forget all the other datagram-oriented protocols that have
>> preceeded - so perhaps there will be some re-innovation.
>> >
>> > >>
>> >
>> > >> I am glad that we agree. Now, we have an issue regarding security.
>> Nicolas Kuhn and his coauthors have pursued a design in which the server
>> sends an encrypted blob to the client, and then client echoes it in the new
>> connection. This is largely based on concerns about potential attacks.
>> Suppose the client said "I received at 1Gbps last time", when in fact it
>> can only absorb 10 Mbps. Some bad stuff might well be happening along the
>> way. But then, Matt is looking at passing statistics from server to client,
>> so the client can debug issues, display statistics in the app, and
>> potentially also reuse the statistics to inform server that the last
>> connection had an RTT of 600 ms and a data-rate of 100 Mbps, and maybe we
>> should shortcut initial congestion control in order to gain lots of time.
>> How do we reconcile these multiple goals?
>> >
>> > >
>> >
>> > > I think that the answer is simple.
>> >
>> > >
>> >
>> > > Loss recovery and CC states are properties maintained by an endpoint.
>> The peer should not be given the right to change them (e.g., CWND, RTT).
>> Servers might offload the state to the client, but that state has to be
>> encrypted and integrity-protected. NEW_TOKEN tokens cover this purpose.
>> >
>> > >
>> >
>> > > OTOH, servers can expose any information to the client regarding the
>> quality of the connection. It is totally reasonable to give the client the
>> bandwidth information that the server retains, so that the client could
>> choose a good bandwidth. There are no security concerns providing such
>> information, regardless of the medium being a QUIC frame or a HTTP header.
>> And that's because it does not affect loss recovery or CC.
>> >
>> > >
>> >
>> > >> -- Christian Huitema
>> >
>> > >
>> > >
>> > > --
>> >
>> > > Kazuho Oku
>> >
>>
>>
>
> --
> Kazuho Oku
>