Is consent freshness really necessary?

[martinthomson]

Consent freshness is currently listed as a security requirement on the protocol. It is something that WebRTC explicitly requires. This is something that QUIC can provide, but does not by default.

There are significant performance implications to continual consent validation as it results in something akin to a keep-alive. I would prefer that we not require this. WebRTC is a different context.

[aboba]

"Consent Freshness" makes sense for the P2P specification where the requirement is met by RFC 7675, but it does not make sense here.

[vasilvv]

Martin, could you clarify what you mean when you say that QUIC does not provide consent validation? I am under impression that every ack-based protocol provides it by design.

[martinthomson]

QUIC does provide consent validation (what it calls address validation) as part of the handshake. It also provides mechanisms for refreshing consent, but it does not automatically provide that on a continuous basis in the same way that WebRTC does. In fact, it isn't wise to do continuous validation as that generates traffic.

That ACKs provide address validation is a common misconception, so it's worth explaining. ACK frames contain relatively low entropy, so it is fairly easy for an attacker to spoof an acknowledgment. If you were to rely on acknowledgments, the attacker could easily guess when you sent a packet and what the packet number of that packet was. That would allow it to also spoof an ACK frame, which would appear to provide consent, but it wouldn't be meaningful as it offers no real proof that the acknowledged packet was received.

The PATH_CHALLENGE frame that is used for address validation in QUIC contains 64 bits of entropy, which is considerably harder to guess. You need to use something like that to get address validation. (For reference, TCP has half that much in the SYN cookie, and that works well enough.)

[vasilvv]

I'm confused. Who would spoof the acknowledgements, given that those are encrypted?

[martinthomson]

The purpose of address validation is to confirm that the holder of the address is willing to accept packets. However, if an attacker can successfully spoof its source address AND the validation process, the other side will believe that the address is accepting packets. At that point it will send toward that address with the only restriction being the congestion controller. That might be turned to the attacker's advantage if their goal is to DoS that address.

A lot here depends on things like how much work the attacker needs to spend and how much the sender will send in terms of what they gain, but in theory the gain could be quite large.

[aboba]

@martinthomson I do think that may be a problem here, but it isn't "consent freshness". The problem that RFC 7675 is trying to solve is voice and video "hammer", that is, a DDOS attack. This was a concern in WebRTC because RTP (unlike QUIC) does not require connection setup.

A distinct concern is whether a sender will stop sending if a receiver is unable to keep up, either at the transport layer (which can be detected via transport ACKs) or application layer (which requires application layer ACKs). In WebRTC, that concern was addressed via RTP congestion control and RTP circuit breakers RFC 8083, with generic requirements described in RFC 8084.

My question is whether there is an equivalent protection in WebTransport. For reliable streams, I think there is. I am not sure about datagrams. For example, a (bad) implementation of RTP over QuicTransport (e.g. a poorly written Javascript library) might not support RFC 8083 or meet the requirements of RFC 8084, and I don't think that QUIC datagrams provide all the required protections. For example, a bad RTP over QuicTransport implementation might not support RTCP (e.g. a port of a legacy RTP stack), and therefore might not support the RTCP timeout circuit breaker. Or there could be an issue in a decoder (e.g. the endpoint CPU might not be powerful enough for WebCodecs to decode a 4K AV1 stream), even though everything is fine at the transport layer (e.g. the QUIC datagrams are being received and acknowledged).

[martinthomson]

If we have a problem here, then we have a problem in QUIC more generally. It might pay to take inventory of the options available here.

Streams provide back pressure through flow control, which also has connection-level controls. Though QUIC DATAGRAM frames aren't flow controlled, so there is no firm protection there.

What you seemed concerned about here is that QUIC is congestion controlled, even for DATAGRAM frames, which addresses the 8083/8084 concerns. The browser operates the congestion controller (modulo Victor's aspirations to have plugable logic), so a bad application can't cause a browser to generate excessive rates.

QUIC has address validation for each new network path. The question I was asking was whether continuous re-validation of addresses was necessary, as implied by using the RFC 7675 term "consent freshness".

The other thing is that QUIC is connection-oriented and endpoints can terminate misbehaving connections, using either an explicit close or a stateless reset. The latter probably only makes sense for servers in this context. Thus, as long as an endpoint has been involved in the connection, they can end it any time that it becomes too hard to tolerate.

Out of all of that, the only question I have is that - within the envelope described - what space there is for a sender to generate traffic that the receiver might not tolerate. DATAGRAM frames are one obvious vector here, but I would suggest that any risk we have of providing tools that might overwhelm a receiver is now comparable to just letting them send anything at all.

If too much AV1 is too much, then as DATAGRAM frames the receiver doesn't have any backpressure mechanism to rely on, but that is an inherent consequence of giving them DATAGRAMs. If we allow for no RTCP, we've basically already accepted a similar risk with WebRTC.

Either way, I figure that we signed up for that particular risk when we embarked on this project.

[aboba]

I agree that the sender has limited ability to generate reliable stream data that a receiver cannot tolerate, due to address validation and the ability of endpoints to terminate misbehaving streams. For reliable streams we also have congestion control and flow control, which should (in theory) influence application behavior via WHATWG streams backpressure.

However, I'm not as sanguine with respect to datagrams, since the WebTransport API doesn't provide the optional functionality described in Section 5.3 of draft-ietf-quic-datagram:

"The sender implementation MUST either delay sending the frame until the controller allows it or drop the frame without sending it (at which point it MAY notify the application). Implementations can optionally support allowing the application to specify a sending expiration time, beyond which a congestion-controlled DATAGRAM frame ought to be dropped without transmission."

Currently, it's not clear to me that the API works in scenarios like an encoder feeding WebTransport. It would be desirable for WebTransport datagram throughput to propagate back to the encoder to allow it to adjust the encoding rate, but I don't think that we get this automagically from "WHATWG Streams backpressure".

In the case of insertable streams raw media (breakout box) we are now talking about explicitly adding feedback to the WHATWG Streams model, so as to allow this kind of back propagation.

[martinthomson]

I read those requirements (from S5.3 of -datagram) as being about reliability alone. That would have little bearing on this discussion. Instead, I would suggest that the text acknowledges that DATAGRAM frames might not have sufficient congestion control credit to allow them to be sent immediately, which suggests some need to hold them.

The API that might be required to deal with this is important but I would prefer if we move that to another issue.

As for Insertable Streams (this should be called Encrypted Media Transform or something like that), I think that depends on an RTCP-specific mechanism, I would think. As the increase in size is modest, it might not even need that. Again, I suggest that is something for another issue.

[aboba]

The question is whether there is a requirement that we should be including instead of "consent freshness" which doesn't seem to apply. One potential citation might be RFC 8084, but the CB requirement doesn't appear to apply to WebTransport (unless it is used for tunneling):

" CBs are RECOMMENDED for IETF protocols and tunnels that carry non- congestion-controlled Internet flows and for traffic aggregates. This includes traffic sent using a network tunnel. Designers of other protocols and tunnel encapsulations also ought to consider the use of these techniques as a last resort to protect traffic that shares the network path being used."

RFC 8083 is another potential citation but the requirements would apply to an application built on WebTransport, rather than to WebTransport itself (e.g. on an RTP over QUIC library).

The datagram issues appeared to be covered: https://github.com/w3c/webtransport/issues/21 https://github.com/w3c/webtransport/issues/36 https://github.com/w3c/webtransport/issues/62 https://github.com/w3c/webtransport/issues/97 https://github.com/w3c/webtransport/issues/105

[martinthomson]

It's right there in the quote, circuit breakers don't apply to a congestion-controlled flow. If we ultimately decide to provide congestion control APIs, we can talk about what safeguards to put in place. Until then, I don't think that there is anything we should mandate.

Should we discover a new vulnerability, we can change the conditions under which browsers perform address validation, which is available at their discretion.

[vasilvv]

Consider a trivial purely datagram-based WebTransport protocol that is just DTLS. In the beginning of the connection, the user agent can verify that the server is willing to talk to it; the DTLS handshake has enough features for such verification. However, as the session goes on, the user agent does not have any reason to assume that the server is still willing to talk to it, as DTLS does not provide any visibility into the connection state post-handshake. That is a problem that QUIC and TCP do not have, as lack of acks from the server will eventually cause the user agent to give up.

I feel like we should capture that property. If "consent freshness" is a misleading description, we should find a better term.