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

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