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

["Eric Vyncke (evyncke)" <[e-mail]>]

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 <[e-mail]>
Date: Thursday, 10 September 2020 at 16:28
To: Eric Vyncke <[e-mail]>
Cc: DISPATCH <[e-mail]>, "[e-mail]" <[e-mail]>, The IESG <[e-mail]>
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