Re: [Moq] E2E encryption

[Luke Curley <[e-mail]>]

Hey all,

My original idea in warp-02 is that every stream started with a HEADERS
message containing the send order, so control messages could be prioritized
alongside data messages. I'm not sure this is necessary though.


Here's my current mental model:

*Data streams are end-to-end*. The relay is unaware of the contents of the
data steam, outside of a few forwarding instructions in the header. ex.
OBJECT
*Control streams are hop-to-hop*. The relay is aware of the contents of the
control stream and uses it to change its behavior. This can include
propagating a message to an upstream depending on deduplication. ex.
SUBSCRIBE


Does this make sense? It's a similar design to HTTP/3, although without
QPACK complicating the picture.


We still might use control streams for end-to-end purposes, like
authentication, but any bulk transfers should be over a data stream. I
think we can safely say that control streams are always the highest
priority.


On Wed, Mar 22, 2023, 8:26 AM Suhas Nandakumar <[e-mail]> wrote:

>
> On the control channel, PRs 96
> <https://github.com/kixelated/warp-draft/pull/96> and 97
> <https://github.com/kixelated/warp-draft/pull/97> does provide support
> for it. PR needs to be updated to reflect the multiple tracks in one
> subscribe/publish message, if needed.
>
> Also moq-transport
> <https://datatracker.ietf.org/doc/html/draft-nandakumar-moq-transport-00#section-4.1>
> proposes some ideas along those lines.
>
> Agree that we need to discuss the scope and usage of control and data
> streams in general.
>
> Also  on E2E encryption, we need to spend some time defining its scope
> (what aspect of OBJECT payload it applies to) and implications. For control
> messages themselves, there might be few cases where one has to carry a
> payload that is end to end encrypted and the same E2EE properties might
> apply as well.
>
>
>
>
>
>
> On Wed, Mar 22, 2023 at 5:59 AM Chuan Ma <[e-mail]> wrote:
>
>> Dear All:
>>
>> I agree that we should define a control stream to offer
>> reliable transmission and be marked with the highest priority. Such a
>> stream can not only solve the problem of E2E authentication but also
>> transmit other control messages, such as updates of subscriptions. The side
>> effect mentioned in Hang's reply may be solved by leaving multiple control
>> stream channels and assigning different priorities to them. Then it is
>> possible to avoid head-of-line blocking in the control stream and helps to
>> offer a flexible extension to MoQ endpoints.
>>
>> Nevertheless, this issue heavily depends on the design of the behavior of
>> the MoQ relays. The critical question is that a relay may act differently
>> when it receives different types of OBJECTS while the data is encrypted. In
>> this discussion, we have at least two basic behaviors of a relay: changing
>> the sending order of packets and dropping the packets. If we try to solve
>> this problem by adding more flags to the OBJECT, we should first define all
>> the possible behaviors the relay can do and how to use the flag to
>> enable/disable a behavior. Considering the current MoQ's design, there may
>> be other scenarios when the relay must act differently, and we may define
>> more relay behaviors. So it may be better for us to clarify* "What kinds
>> of service the relay should offer" *and* "How the endpoint should 'ask
>> for' the transport service the relays offer*." In the current scope, I'd
>> like to say if we are trying to hide the relays from the endpoints, then we
>> should design something like control flows; if we are trying to make the
>> relays cooperate with the endpoints, then we should consider ways to change
>> the relay's action like using flags. How do you like this idea?
>>
>> Thanks,
>> Chuan Ma
>>
>> On Wed, Mar 22, 2023 at 4:20 PM Shihang(Vincent) <shihang9=
>> [e-mail]> wrote:
>>
>>> It seems like the requirement of the E2E encryption is that some
>>> message/OBJECT needs to be transmitted reliably. Are there any other
>>> messages(SUBSCRIBE/SETUP/GOAWAY/CATALOG) sharing the same reliability
>>> requirement?
>>>
>>> This is related to https://github.com/kixelated/warp-draft/issues/105
>>> proposed by Luke. We can specify a dedicated stream(say stream 0) for these
>>> messages which needs to transmitted reliably and ASAP(which means highest
>>> priority). All other streams can be used to transmit the media data OBJECT
>>> which can be dropped. The side effect of a dedicated stream is that they
>>> all share the same priority, will be delivered in order(which implies that
>>> the newer message depends on the older message). Are these side effects
>>> acceptable?
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Hang
>>>
>>> *From:* Moq <[e-mail]> *On Behalf Of *Luke Curley
>>> *Sent:* Tuesday, March 21, 2023 7:41 AM
>>> *To:* Suhas Nandakumar <[e-mail]>
>>> *Cc:* Mo Zanaty (mzanaty) <mzanaty=[e-mail]>; Victor
>>> Vasiliev <vasilvv=[e-mail]>; Cullen Jennings <
>>> [e-mail]>; MOQ Mailing List <[e-mail]>
>>> *Subject:* Re: [Moq] E2E encryption
>>>
>>>
>>>
>>> Hey Suhas,
>>>
>>>
>>>
>>> We could add an incremental (or atomic) flag. It makes sense in Mo's
>>> example; when packaging multiple frames into a single authenticated OBJECT
>>> payload. I would still add text to say that a relay SHOULD NOT buffer
>>> objects, even when flagged as atomic, because that will add latency at each
>>> hop.
>>>
>>>
>>>
>>> On an implementation detail, we could reuse the message size. A size of
>>> 0 means incremental and continues until the end of the stream, while a
>>> non-zero size means atomic and the specified number of bytes. A separate
>>> flag works too.
>>>
>>>
>>>
>>>
>>>
>>> As for auth tags, the premise of end-to-end encryption is that a
>>> middle-man (relay) cannot modify or drop any of the payload, including the
>>> signature. The signature doesn't need any special treatment and should just
>>> be part of the opaque object payload; with AEAD it's usually just appended
>>> to the ciphertext. Could you explain why you think this would be an attack
>>> vector?
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Mar 20, 2023 at 11:40 AM Suhas Nandakumar <[e-mail]>
>>> wrote:
>>>
>>> Hey Luke,
>>>
>>> On Mon, Mar 20, 2023 at 10:49 AM Luke Curley <[e-mail]>
>>> wrote:
>>> >
>>> > On Mon, Mar 20, 2023 at 10:12 AM Mo Zanaty (mzanaty) <mzanaty=
>>> [e-mail]> wrote:
>>> >>
>>> >> The problem is if relays are blind to E2E authentication, they can
>>> make poor delivery decisions. For example, delivering most or all packets
>>> except the last packet containing the E2E auth tag, which is highly likely
>>> in a scheme like warp which starves or drops the tail of old data to send
>>> new data.
>>> >
>>> >
>>> > Just to clarify, Warp will only starve the tail of an OBJECT during
>>> congestion if you send an even more important OBJECT (decreasing send
>>> order). If you're going to put the auth tag at the end of a large object
>>> (ex. an entire GoP), then you're going to want some form of head-of-line
>>> blocking (increasing send order). Or possibly an incremental flag like
>>> HTTP/3 Priority to indicate when OBJECTs are (not) atomic.
>>>
>>> That would work if we define how to identify the incremental chunks
>>> and define where to find the authn tag.  Relays need to know this ,
>>> otherwise, there is a security issue when relays don't forward the
>>> authn tag and will be an attack vector.
>>>
>>> Thoughts ?
>>>
>>> > --
>>> > Moq mailing list
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/moq
>>>
>>> --
>>> Moq mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/moq
>>>
>>