Re: [Sframe] Paul Wouters' Discuss on draft-ietf-sframe-enc-07: (with DISCUSS)

[Richard Barnes <[e-mail]>]

Hi Paul,

Thanks for the review.  Responses inline...

On Thu, Apr 4, 2024 at 6:57 AM Paul Wouters via Datatracker <
[e-mail]> wrote:

> 1) KID and CTR encoding
>
> Is there really much to be gained from the SFrame Header KID and CTR
> encoding
> for small values? For example an audio or video stream would almost
> immediately
> require the "extended encoding" for the CTR? I find it difficult to see the
> advantage of this added complexity.
>

The compressed encoding is definitely useful for KID values.  For small
sessions (e.g., 1:1), you might never need more than a handful of KID
values.  The compressed CTR encoding is for parallelism, so that you can
use the same code to process both KID and CTR.

See also my response to John Scudder's COMMENT:
https://mailarchive.ietf.org/arch/msg/sframe/ra0s-A7v9hMM2XBQpgSKj6wc4CQ/



> 2) Tag size
>
> What is the real gain of allowing shorter authentication tags? Even the
> document itself states:
>
>         Nonetheless, without these mitigations, an application that
>         makes use of short tags will be at heightened risk of forgery
>         attacks. In many cases, it is simpler to use full-size tags and
>         tolerate slightly higher bandwidth usage rather than add the
>         additional defenses necessary to safely use short tags.
>
> Why not simplify on just 1 tag size?
>

Media people love to complain about tags :)  Audio streams in particular
tend to send lots of really small packets, so a full GCM tag can add more
than 25% to the bandwidth overhead.  See the overhead analysis in Appendix
C:

https://www.ietf.org/archive/id/draft-ietf-sframe-enc-07.html#name-audio

At the same time, as the document describes, it is possible to use short
tags safely in some circumstances. So the WG decided to allow folks some
flexibility.


3) IANA Considerations
>
> Have you considered splitting the ciphersuites into a part that
> requires standards action and a part that is specification required?
>
> Related, have you considered using a RECOMMENDED column for ciphersuites,
> where a RECOMMENDED=y can only be done via standards action?
>

Roman also raised something like this point in his NO OBJ:
https://datatracker.ietf.org/doc/draft-ietf-sframe-enc/ballot/#draft-ietf-sframe-enc_roman-danyliw

I filed a PR making following the same RECOMMENDED pattern as MLS and TLS:
https://github.com/sframe-wg/sframe/pull/196