[Sframe] Deb Cooley's No Objection on draft-ietf-sframe-enc-07: (with COMMENT)

[Deb Cooley via Datatracker <[e-mail]>]

Deb Cooley has entered the following ballot position for
draft-ietf-sframe-enc-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sframe-enc/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to Carl Wallace for his review.  I checked some of his nits, and they
appear to be addressed, even though there was nothing on the mailing list to
indicate that (at least not directly).

I thought this was well written.  I view these as pretty minor comments.  I'm
happy to discuss them, and adjust.

Section 4.1, 7.1:  "an E2EE layer over an underlying HBH-encrypted transport". 
It would be clearer to say "an E2EE layer inside a HBH-encrypted transport". 
Obviously the HBH encryption has to be on the outside, right?  I'm assuming
that 'over' means above it in the protocol stack.  If this is a common way to
say this in the IETF, then it is fine (I'll get used to it eventually).

Section 4.4.1, para 2:  Potential re-use of counter values would be reduced in
implementations if the previous counter value was stored (currently next
counter is stored).  The client increments (and stores) at the start vice after
the counter is used. It eliminates a failure to store the next value.  Only my
opinion... If there are many implementations already, then I withdraw the
comment.  Confusion caused mid implementation is worse than leaving it alone.

Section 4.4.2:  If 'sframe_key_label' and 'sframe_salt_label' is 'info' in the
HKDF computation, that should be stated somewhere (or replace 'info' with the
label name).

Section 4.4.3/4.4.4:  Metadata is both encrypted and appended in the clear
(visible to the SFU)?  If so, is the decrypted metatdata compared with the
appended metadata?  Assuming that the metadata is encrypted to provide
integrity... Is this stated somewhere?

Section 4.4.4:  Does the decryptor keep track of CTR state?  If so, what
happens if a CTR value is re-used by the encryptor?  Is the sframe rejected? 
Is there an error sent?  maybe out of band (through the signaling channel)?

Section 4.5.1: For "enc_key_sframe_key[..Nka]" add a comment stating that this
is picking the first Nka bytes.  Also add a comment to "auth_key =
sframe_key[Nka..]" stating to skip Nka bytes to pick the last Nh bytes.  (this
is done as a comment later in the document, so do it here too)

Section 5:  Key management is the responsibility of the application.  And then
there is section 5.1 and 5.2.  Are they options?  Suggestions?  Perhaps add
'Section 5.1 and 5.2 provide two options for partial key management
frameworks.'  (framework might not be the right word, because neither 5.1 nor
5.2 discuss how the base_key gets generated.)