Re: [Sframe] Adoption call for draft-omara-sframe-01

[Eric Rescorla <[e-mail]>]

TL;DR. This document needs a fair bit of work but I think
we should adopt it and work on it in the WG rather than
making the authors do a pile of work beforehand.

At the high level, I tend to agree with Bernard that this is
doing a bit too much. Specifically, while SFrame is designed
to be embedded in an E2E keying system, there's not much
about it that requires E2E. I would consider breaking that
material out into a different document or perhaps moving
it into an appendix as stage setting.

I also think it would be good if the document were somewhat
more agnostic about SPacket and SFrame; it seems like each
version has advantages in some cases.


DETAILED COMMENTS
S 4.

The stuff here 4. seems informational.

   We propose a frame level encryption mechanism that provides effective
   end-to-end encryption, is simple to implement, has no dependencies on
   RTP, and minimizes encryption bandwidth overhead.  Because SFrame
   encrypts the full frame, rather than individual packets, bandwidth
   overhead is reduced by having a single IV and authentication tag for
   each media frame.

As noted above, there's nothing E2E about this. It's just designed to
it into a certain setting. I *do* think it would be useful to explain
the extent to which this depends on SRTP for security, if at all.


S 4.2.
   Since each endpoint can send multiple media layers, each frame will
   have a unique frame counter that will be used to derive the
   encryption IV.  The frame counter must be unique and monotonically
   increasing to avoid IV reuse.


   Reserved (R): 1 bit This field MUST be set to zero on sending, and
   MUST be ignored by receivers.  Counter Length (LEN): 3 bits This
   field indicates the length of the CTR fields in bytes (1-8).

I am having trouble reading this text. Is it saying that the CTR field
can be 1-8 bytes long? But of course, 3 bits can only encode 0-7, so
you need to explain it's +1, I guess?


S 4.3.5.

   Unlike messaging application, in video calls, receiving a duplicate
   frame doesn't necessary mean the client is under a replay attack,
   there are other reasons that might cause this, for example the sender
   might just be sending them in case of packet loss.

This is true for messaging as well.

   SFrame decryptors
   use the highest received frame counter to protect against this.  It
   allows only older frame pithing a short interval to support out of
   order delivery.

Should this say "within". You will eventually need more detail here
about how this works. In particular, you shouldn't update until you
have decrypted.


S 4.4.

     +========+==========================+====+====+====+===========+
     | Value  | Name                     | Nh | Nk | Nn | Reference |
     +========+==========================+====+====+====+===========+
     | 0x0001 | AES_CM_128_HMAC_SHA256_8 | 32 | 16 | 12 | RFC XXXX  |
     +--------+--------------------------+----+----+----+-----------+
     | 0x0002 | AES_CM_128_HMAC_SHA256_4 | 32 | 16 | 12 | RFC XXXX  |
     +--------+--------------------------+----+----+----+-----------+
     | 0x0003 | AES_GCM_128_SHA256       | 32 | 16 | 12 | RFC XXXX  |
     +--------+--------------------------+----+----+----+-----------+
     | 0x0004 | AES_GCM_256_SHA512       | 64 | 32 | 12 | RFC XXXX  |
     +--------+--------------------------+----+----+----+-----------+

A 4 byte tag is pretty short.

What's the reason for specifyin anything with SHA-512 as the
KDF?


   In a session that uses multiple media streams, different ciphersuites
   might be configured for different media streams.  For example, in
   order to conserve bandwidth, a session might use a ciphersuite with
   80-bit tags for video frames and another ciphersuite with 32-bit tags
   for audio frames.

A little weird to say this when you don't specify anything with 80 bit
tags.








On Sun, Oct 10, 2021 at 4:36 PM Martin Thomson <[e-mail]> wrote:

> https://datatracker.ietf.org/doc/html/draft-omara-sframe-01
>
> Please respond to this email before AOE 31 October 2021 if you support
> adopting draft-omara-sframe (currently -01) as a working group item.  If
> you would prefer we not adopt this work, please respond with an explanation
> of why and ideally what you would like to see addressed before we do that.
>
> We're running this a tiny bit longer than a typical adoption call.  Last
> time we talked about adoption there were a few concerns raised about the
> draft.  We want to make sure those concerns are addressed, or at least
> those with concerns are satisfied that their concerns could be addressed.
>
> Martin, for the chairs
>
> --
> Sframe mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sframe
>