Re: [Sframe] John Scudder's No Objection on draft-ietf-sframe-enc-07: (with COMMENT)

[Richard Barnes <[e-mail]>]

Hi John,

Thanks for taking a look.

Re "external" - Fair point.  To elaborate a little, the objective here is
to prevent timing attacks by  a few potential classes of attacker: Network
attackers, the SFU, other endpoints, or other software on the subject
endpoint.  Network attackers are constrained by the HBH protection we
assume exists.  Endpoints are unlikely to get high-resolution timing
measurements.  The SFU has the ability to send the endpoint synthesized
ciphertexts within the HBH channel, as well as a more direct connection to
the endpoint that would facilitate good timing measurement.  Similar story
for other software on the host.

The high-level message, though, is that `SFrameContext::decrypt()` should
be a constant-time operation, irrespective of whether the decryption is
successful or not.  I think the current text is close enough to capture
that, but would be open to clarifying further.

Re compressed CTR representation -- You're correct that the 3-bit CTR
representation is not that useful, and in fact, it used to not exist (that
field was always CLEN).  We changed it so that you could use the same logic
to process both KID and CTR:

https://github.com/sframe-wg/sframe/pull/140

Cheers,
--Richard





On Wed, Apr 3, 2024 at 10:28 AM John Scudder via Datatracker <
[e-mail]> wrote:

> John Scudder has entered the following ballot position for
> draft-ietf-sframe-enc-07: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sframe-enc/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for this document. To the extent I’m qualified to review it, I
> found it
> clear, comprehensive, and readable. I have a minor comment and a trivial
> question.
>
> Comment:
>
> “Invalid ciphertexts SHOULD be discarded in a way that is
> indistinguishable (to
> an external observer) from having processed a valid ciphertext.”
>
> This might be clear to someone within your ecosystem, but I wonder what
> exactly
> is meant by “external” here. I infer it means an observer without any
> access to
> a system that’s participating in the conference, because otherwise, I
> don’t see
> how this requirement could be met (consider the case where the discarded
> ciphertext is a keyframe, for example).
>
> Whether this calls for clarification or not is up to you.
>
> Question:
>
> I also wonder as to the practical value of the compressed CTR
> representation —
> I would have imagined that most use cases would emit more than 8
> plaintexts,
> and for that matter, if there are 8 or fewer plaintexts to be emitted over
> the
> lifetime of the KID, the application is so low-volume that maybe the
> optimization doesn’t buy you much as compared to, say, adding another bit
> to
> the compressed KID field.
>
> But this is just idle curiosity, even if the answer was “yeah, it’s not
> that
> useful” I wouldn’t advocate changing the encoding at this late date.
>
>
>
>