Re: [Sframe] Publication has been requested for draft-ietf-sframe-enc-06

Inline...

On Wed, Jan 31, 2024 at 7:48 PM Murray S. Kucherawy <superuser@gmail.com>
wrote:

>
> Hello all,
>

Hello Murray!

> Sorry this has taken me so long to get through.  Overall I think it's
> quite well done and what I've managed to come up with is mostly minor.  So,
> here's what I've got so far; rather than have you keep waiting on more
> comments or questions, I'm going to request Last Call now in parallel with
> me finishing my review.  We can deal with these alongside any Last Call
> feedback and directorate reviews if you like.
>

Sounds good to me.  I filed a PR for your comments:
https://github.com/sframe-wg/sframe/pull/183

> In no particular order:
>
> Section 8:
>
> This kind of reads like at one point you were asking for multiple
> registries, but only one remains.  Some of the grammar mismatches should be
> tidied up.
>

Done.

> Per RFC 8126, a "Specification Required" registry strongly encourages
> advice to the Designated Expert about what one should consider when
> deciding if the reference being offered is satisfactory, but no such advice
> is present here.  Do we need any?
>

I think the RFC's guidance is sufficient. ("documented in a permanent and
readily available public specification, in sufficient detail so that
interoperability between independent implementations is possible")

> Section 4.4.1:
>
> I'm a stickler for correct use of SHOULD, so I'm going to test a couple of
> these.  In this section, there's a SHOULD mark keys one way or the other,
> but never both.  Since SHOULD allows a choice, is there ever a reason to
> mark a key as both?  Or should that really be a MUST?
>

I think you're right on this one.

> Section 4.4.4:
>
> Same SHOULD question.
>

This one is "SHOULD" as in "it's complicated". For example:

* Not all crypto libraries are constant-time in this way
* In some systems, failures will manifest to higher layers as dropped
packets, which may end up in things like RTCP reports.

The attacks that would be enabled by failing to meet the requirement are
conditional in some similarly complicated ways.  So it's not an "absolute
requirement"; thus SHOULD.

There's also a SHOULD in Section 7.3, which is conditional in a similar
way.  The desired FS/PCS properties vary among applications, and it's not
up to this specification to enforce a specific set of properties at this
level.

> Section 9.3:
>
> Are there any informative references that might be offered regarding the
> mitigations suggested here?
>

Added a citation to the SRTP algorithm.

>
> Section 7.5:
>
> The first bullet appears to be one sentence that's been broken into two.
>

So you don't like the initial "So".  Reworded.

--RLB

>
> -MSK
>
>
> --
> Sframe mailing list
> Sframe@ietf.org
> https://www.ietf.org/mailman/listinfo/sframe
>