Re: [Moq] E2E encryption

[Suhas Nandakumar <[e-mail]>]

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
>>
>