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

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