[Sframe] Benjamin Kaduk's No Objection on charter-ietf-sframe-00-02: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 05 November 2020 16:03 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: sframe-chairs@ietf.org, sframe@ietf.org, dispatch@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <160459217995.25275.15999743679552040874@ietfa.amsl.com>
Date: Thu, 05 Nov 2020 08:02:59 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sframe/yODDawCvRYrgIJVE5vEgDSwKTVU>
Subject: [Sframe] Benjamin Kaduk's No Objection on charter-ietf-sframe-00-02: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
charter-ietf-sframe-00-02: 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.)



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



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

   This working group, however, will not specify the signaling required to
   configure SFrame encryption.  In particular, considerations related to SIP or
   SDP are out of scope.  This is because SFrame is intended to be applied as an
   additional layer on top of the base levels of protection that these protocols
   provide.  [...]

This text reads like it is saying that SIP and SDP provide "base levels of protection",
which is not necessarily the case in the context of the protection that SFrame provides.

    It is anticipated that several use cases of SFrame will involve its use with
    keys derived from the MLS group key exchange protocol.  The working group will
    define a mechanism for doing SFrame encryption using keys from MLS, including,
    for example, the derivation of SFrame keys per MLS epoch and per sender.

It may be worth adding another sentence here to reiterate that just because MLS
is complicated and may need special integration, that does not preclude using
SFrame with other sources of key material.

[Sframe] Benjamin Kaduk's No Objection on charter… Benjamin Kaduk via Datatracker