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

[Paul Wouters <[e-mail]>]

Thanks for the update Richard, I've updated my ballot to Yes based on your
response.

Paul

On Thu, Apr 4, 2024 at 9:25 AM Richard Barnes <[e-mail]> wrote:

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