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

[Richard Barnes <[e-mail]>]

Just posted draft-07.  To the IESG!


On Thu, Feb 29, 2024 at 9:58 AM Richard Barnes <[e-mail]> wrote:

> 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 <[e-mail]>
> 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 <[e-mail]>
>> 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 <[e-mail]> wrote:
>>>
>>>> Inline...
>>>>
>>>> On Wed, Jan 31, 2024 at 7:48 PM Murray S. Kucherawy <
>>>> [e-mail]> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/sframe
>>>>>
>>>>