Re: [Moq] E2E encryption

[Suhas Nandakumar <[e-mail]>]

Hi Luke,


On Wed, Mar 22, 2023 at 4:56 PM Luke Curley <[e-mail]> wrote:
>
> 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.

The transport-draft (stream-mappings
<https://datatracker.ietf.org/doc/html/draft-nandakumar-moq-transport-00#section-4.2>)
refers to the following arrangements for the data streams as a mapping from
the data model
to QUIC streams( which is taken from QUICR design)

For cases where the application wants to send multiple objects in one
stream ( GOP per stream)
   +--------+------------+-------+------------+-------+------
   | Group  | Object     | Bytes | Object     | Bytes |
   | header | header (0) |  (0)  | header (1) |  (1)  | ...
   +--------+------------+-------+------------+-------+------

For cases where the application wants to send one object per stream ( one
encoded frame per stream)

   +--------+------------+-------+
   | Group  | Object     | Bytes |
   | header | header (n) |  (n)  |
   +--------+------------+-------+

with Group Header defined as

 group_header {
     message_type(i),
     media_id(i),
     group_id(i)
   }

media_id is a hop-by-hop short-form identifier mapping to the track_id. The
media_id
gets set up as part of control message exchange (publish/subscribe requests)

and Object header defined as

object_header {
     message_type(i),
     object_id(i),
     [nb_objects_previous_group(i),]
     flags[8],
     object_length(i)
   }

This will enable per object priority captured in the flags field.

Something like this will give flexibility for applications to define the
object granularity as
it fits their requirements and units for applying the end to end encryption
where necessary.

I know this model doesn't include sendOrder and we need to discuss options
for one vs the other as
it applies to multiple use-cases.

Does something like this work for you for describing the data streams to
have group_header, [object_header, object bytes]...
kind of setup ?
>
>
> 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 and 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 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