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

We have pull requests covering all the reviews so far.

https://github.com/sframe-wg/sframe/pulls

I'll get them reviewed and merged ASAP, then send you a new draft.

On Thu, Feb 29, 2024 at 9:52 AM Murray S. Kucherawy <superuser@gmail.com>
wrote:

> ...and, I guess, any necessary responses to the other directorate reviews
> (SEC, ART)?
>
> -MSK
>
> On Thu, Feb 29, 2024 at 8:52 AM Murray S. Kucherawy <superuser@gmail.com>
> wrote:
>
>> Thanks for these; can we expect a -07 with that PR incorporated before I
>> send it to the IESG?
>>
>> -MSK
>>
>> On Thu, Feb 1, 2024 at 2:37 PM Richard Barnes <rlb@ipv.sx> wrote:
>>
>>> 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
>>>>
>>>