Subject: [Sframe] Éric Vyncke's Block on charter-ietf-sframe-00-00

From: Richard Barnes <[email-masked]>
Date: Thu, 10 Sep 2020 10:27:22 -0400

Hi Éric,

For some reason, your Block didn't get sent to the relevant mailing lists,
so I'm crafting my own reply :)

- 'Selection among multiple encryption keys' should there be a way to use
> different encryption algorithm as well with the encapsulation (I noted that
> this bullet is explicitly for inside a session)?
>

No.  The assumption is that the algorithm is fixed for a given flow, but
there may be multiple keys (e.g., for different senders), and of course,
each encrypted unit needs a different nonce.  We could add some text to
clarify this if you think it's really necessary, but this seems like a
finer level of granularity than is needed in a charter.

> - like Magnus, I find "Information to form a unique nonce" pretty vague
> and is it 'nonce' or more 'initialization vector' ?
>

I've revised to be clear that the encapsulation has a standard nonce
formation algorithm, and the wire format provides the input to it.  The
word "nonce" is standard here (see
https://tools.ietf.org/html/rfc5116#section-2.1)

> - 'This working group will not specify the signaling required to configure
> SFrame encryption", it is unclear to me whether the WG will specify a
> control channel to negotiate keys and crypto algorithms as the current
> sentence appears more generic configuration (e.g., supported crypto
> algorithms)
>

No, the WG will not specify a control channel.  That is something the
application will have to provide.

> - only one milestone ? There is nothing about the RTP mapping document
> that is mentioned in the charter text
>

Yep.  Just one thing, the encapsulation.  The MLS mapping and RTP
considerations should both be small enough to be sections in that document.

--Richard

---

From: Emad Omara <[email-masked]>
Date: Mon, 14 Sep 2020 22:20:30 -0700

Hi Eric,

Did Richard's responses address your concerns? Please let us know if you
have more questions or concerns.

Emad

On Thu, Sep 10, 2020 at 7:28 AM Richard Barnes <[email-masked]> wrote:

>> - 'This working group will not specify the signaling required to
>> configure SFrame encryption", it is unclear to me whether the WG will
>> specify a control channel to negotiate keys and crypto algorithms as the
>> current sentence appears more generic configuration (e.g., supported crypto
>> algorithms)
>>
>
> --
> Sframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sframe
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 15 Sep 2020 05:53:29 +0000

Richard

Sorry for belated reply, I am enjoying some days off.

As I in my BLOCK, it is more about being really clear in the charter than having real issues with the charter.

See in-line for EV>

From: Richard Barnes <[email-masked]>
Date: Thursday, 10 September 2020 at 16:28
To: Eric Vyncke <[email-masked]>
Cc: DISPATCH <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>
Subject: Éric Vyncke's Block on charter-ietf-sframe-00-00

Hi Éric,

For some reason, your Block didn't get sent to the relevant mailing lists, so I'm crafting my own reply :)

- 'Selection among multiple encryption keys' should there be a way to use different encryption algorithm as well with the encapsulation (I noted that this bullet is explicitly for inside a session)?

No.  The assumption is that the algorithm is fixed for a given flow, but there may be multiple keys (e.g., for different senders), and of course, each encrypted unit needs a different nonce.  We could add some text to clarify this if you think it's really necessary, but this seems like a finer level of granularity than is needed in a charter.

EV> OK, the text is still vague though about “selection” because it is probably “rotation” or “refreshing”

- like Magnus, I find "Information to form a unique nonce" pretty vague and is it 'nonce' or more 'initialization vector' ?

I've revised to be clear that the encapsulation has a standard nonce formation algorithm, and the wire format provides the input to it.  The word "nonce" is standard here (see https://tools.ietf.org/html/rfc5116#section-2.1)

EV> While I know what a nonce is, the text will benefit of a change of wording

- 'This working group will not specify the signaling required to configure SFrame encryption", it is unclear to me whether the WG will specify a control channel to negotiate keys and crypto algorithms as the current sentence appears more generic configuration (e.g., supported crypto algorithms)

No, the WG will not specify a control channel.  That is something the application will have to provide.

EV> What about « This working group will not specify the signaling required to derive the SFrame encryption parameters” ?

- only one milestone ? There is nothing about the RTP mapping document that is mentioned in the charter text

Yep.  Just one thing, the encapsulation.  The MLS mapping and RTP considerations should both be small enough to be sections in that document.

EV> OK, then this is fine
--Richard