Skip to main content

Secure Media Frames
charter-ietf-sframe-01

Revision differences

Document history

Date Rev. By Action
2020-11-06
01 Cindy Morgan New version available: charter-ietf-sframe-01.txt
2020-11-06
00-03 Cindy Morgan State changed to Approved from External Review (Message to Community, Selected by Secretariat)
2020-11-06
00-03 Cindy Morgan IESG has approved the charter
2020-11-06
00-03 Cindy Morgan Closed "Approve" ballot
2020-11-06
00-03 Cindy Morgan WG action text was changed
2020-11-05
00-03 Benjamin Kaduk
[Ballot comment]
  This working group, however, will not specify the signaling required to
  configure SFrame encryption.  In particular, considerations related to SIP or …
[Ballot 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.
2020-11-05
00-03 Benjamin Kaduk Ballot comment text updated for Benjamin Kaduk
2020-11-05
00-03 Murray Kucherawy New version available: charter-ietf-sframe-00-03.txt
2020-11-05
00-02 Benjamin Kaduk
[Ballot comment]
  This working group, however, will not specify the signaling required to
  configure SFrame encryption.  In particular, considerations related to SIP or …
[Ballot 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.
2020-11-05
00-02 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2020-11-05
00-02 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-11-05
00-02 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2020-11-05
00-02 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2020-11-05
00-02 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-11-04
00-02 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2020-11-04
00-02 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-11-04
00-02 Alvaro Retana
[Ballot comment]
It's not clear to me what exactly this last piece of text means:

  Input to the WG

  Proposals already existing relating …
[Ballot comment]
It's not clear to me what exactly this last piece of text means:

  Input to the WG

  Proposals already existing relating to this charter proposal:
  https://datatracker.ietf.org/doc/html/draft-omara-sframe-00 


It is just a pointer to existing work?  Is it a statement that the WG should use (or maybe will use) this document as the base for discussion?  Given that the document was the source of the discussion that led to this WG, I assume it's the latter.  Please be clear.
2020-11-04
00-02 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-10-29
00-02 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-10-28
00-02 Barry Leiba
[Ballot comment]
I wonder whether this should be chartered in the Sec Area with an ART AD (Murray) set as responsible AD.

I also think …
[Ballot comment]
I wonder whether this should be chartered in the Sec Area with an ART AD (Murray) set as responsible AD.

I also think the last bit:

    Input to the WG
    Proposals already existing relating to this charter proposal:
    https://datatracker.ietf.org/doc/html/draft-omara-sframe-00

...shouldn't be in the final charter text (it was fine to have it there during review).  The draft is referenced in the milestone, and that should cover it.
2020-10-28
00-02 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-10-26
00-02 Murray Kucherawy
[Ballot comment]
Magnus and Erik had some concerns with the charter text that they chose not to BLOCK on, but I'm still looking into how …
[Ballot comment]
Magnus and Erik had some concerns with the charter text that they chose not to BLOCK on, but I'm still looking into how to get them resolved just to be as thorough as possible.
2020-10-26
00-02 Murray Kucherawy [Ballot Position Update] New position, Yes, has been recorded for Murray Kucherawy
2020-10-22
00-02 Cindy Morgan Telechat date has been changed to 2020-11-05 from 2020-09-10
2020-10-22
00-02 Cindy Morgan WG new work message text was changed
2020-10-22
00-02 Cindy Morgan WG review text was changed
2020-10-22
00-02 Cindy Morgan WG review text was changed
2020-10-22
00-02 Cindy Morgan WG review text was changed
2020-10-22
00-02 Cindy Morgan WG review text was changed
2020-10-22
00-02 Cindy Morgan WG review text was changed
2020-10-22
00-02 Cindy Morgan Created "Approve" ballot
2020-10-22
00-02 Cindy Morgan Closed "Ready for external review" ballot
2020-10-22
00-02 Cindy Morgan State changed to External Review (Message to Community, Selected by Secretariat) from Start Chartering/Rechartering (Internal Steering Group/IAB Review)
2020-10-13
00-02 Éric Vyncke
[Ballot comment]
Still not too happy with some previous DISCUSS points of mine, notably:
- 'This working group will not specify the signaling required to …
[Ballot comment]
Still not too happy with some previous DISCUSS points of mine, notably:
- '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)
2020-10-13
00-02 Éric Vyncke [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Block
2020-10-13
00-02 Magnus Westerlund
[Ballot comment]
Thanks, this update address my significant issues with the charter.

I think the charter might be giving a slightly skewed image of the …
[Ballot comment]
Thanks, this update address my significant issues with the charter.

I think the charter might be giving a slightly skewed image of the granularity question. To my understanding the application data units (ADU) combined with SFRAMEs properties and the underlying transport will in combination define what granularity that are practical to accomplish. As an example an RTP payload format for SFRAMEs that would support multiple SFRAME objects for a set of ADUs belonging to the same video frame would provide great flexibility in how many SFRAMEs the ADUs are protected in. If each ADU is split into multiple SFRAMES that could be supported but maybe unnecessary as the codec likely are unable to process sub-ADUs, at the same time putting multiple ADUs into one SFRAME requires a seperation to exist above SFRAMEs. This type of questions will be application specific and dependent on underlying layers where to support which functionality. I have the impression that the proponents for SFRAME have a desire to have minimal support for this in SFRAME and rather rely on how the application and the transport is capable of applying SFRAMEs to achieve its confidentiality goals.
2020-10-13
00-02 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Block
2020-10-07
00-02 Murray Kucherawy New version available: charter-ietf-sframe-00-02.txt
2020-10-01
00-01 Murray Kucherawy New version available: charter-ietf-sframe-00-01.txt
2020-09-10
00-00 Robert Wilton
[Ballot comment]
This may come up in the context of the document reviews, but given the recent discussions on terminology we may want to proactively …
[Ballot comment]
This may come up in the context of the document reviews, but given the recent discussions on terminology we may want to proactively avoid use of the term 'nonce' in the WG charter.
2020-09-10
00-00 Robert Wilton Ballot comment text updated for Robert Wilton
2020-09-10
00-00 Robert Wilton
[Ballot comment]
This may come up in the context of the document reviews, but given the recent discussions for terminology we may want to proactively …
[Ballot comment]
This may come up in the context of the document reviews, but given the recent discussions for terminology we may want to proactively avoid use of the term 'nonce' in the WG charter.
2020-09-10
00-00 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-09-09
00-00 Benjamin Kaduk
[Ballot comment]
I support Magnus's and Érics' Blocks.

Some additional comments:

    Real-time conferencing sessions increasingly require end-to-end
    protections that prevent intermediary …
[Ballot comment]
I support Magnus's and Érics' Blocks.

Some additional comments:

    Real-time conferencing sessions increasingly require end-to-end
    protections that prevent intermediary servers from decrypting real-time media.
    The PERC WG developed a “double encryption” scheme for end-to-end encryption
    that was deeply tied to SRTP as its underlying transport.  This entanglement
    has prevented widespread deployment.

I thought we were going to tweak this text (noting that RFC RFC 8723 is only a
handful of months old).

It might also be worth a note about the general expected shape of the key
hierarchy (e.g., one key per sender vs. full mesh).

    * Selection among multiple encryption keys in use during a real-time session
    * Information to form a unique nonce within the scope of the key
    * Authenticated encryption using the selected key and nonce

I assume that this means "assembling preexisting crypto building blocks", not
"define new crypto".

    The transport-independence of this encapsulation means that it can be applied
    at a higher level than individual RTP payloads.  For example, it may be
    desirable to encrypt whole frames that span multiple packets in order to
    amortize the overhead from framing and authentication tags.  It may also be
    desirable to encrypt units of intermediate size (e.g., H.264 NALUs or AV1 OBUs)
    to allow partial frames to be usable.  The working group will choose what
    levels of granularity are available and to what degree this can be configured.

(Available as input to the WG of available from its output?)

    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.

Will other sources of key material be considered?
2020-09-09
00-00 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2020-09-09
00-00 Erik Kline
[Ballot comment]
[[ comments/questions ]]

* Agree with "Information to form a unique nonce within the scope of the key"
  seeming a bit underdefined …
[Ballot comment]
[[ comments/questions ]]

* Agree with "Information to form a unique nonce within the scope of the key"
  seeming a bit underdefined at the moment.

* If conferencing migrates to carriage over QUIC, would that have any
  impact on/overlap with this work?
2020-09-09
00-00 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-09-09
00-00 Roman Danyliw
[Ballot comment]
** I share Éric Vyncke concerns with the bulleted list of what SFRAME encapsulation will provide.  My recommendation would be to reframe this …
[Ballot comment]
** I share Éric Vyncke concerns with the bulleted list of what SFRAME encapsulation will provide.  My recommendation would be to reframe this text around what security properties/assurances/services this encapsulation will provide (rather than a functional list).

** If configuring the security services is out of scope, where is it anticipated that this signalling protocol work would occur?
2020-09-09
00-00 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-09-09
00-00 Alissa Cooper [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper
2020-09-09
00-00 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-09-08
00-00 Éric Vyncke
[Ballot block]
I am afraid that this charter is not ready for external review, hence my BLOCK.

Nothing bad in the WG goals (useful work …
[Ballot block]
I am afraid that this charter is not ready for external review, hence my BLOCK.

Nothing bad in the WG goals (useful work to be done) but rather on the way it is written so it should be easy to fix:

- '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)?
- like Magnus, I find "Information to form a unique nonce" pretty vague and is it 'nonce' or more 'initialization vector' ?
- '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)
- only one milestone ? There is nothing about the RTP mapping document that is mentioned in the charter text
2020-09-08
00-00 Éric Vyncke [Ballot Position Update] New position, Block, has been recorded for Éric Vyncke
2020-09-07
00-00 Magnus Westerlund
[Ballot block]
I know we have had discussion touching on this before. But post vacation and looking on this charter again I think we need …
[Ballot block]
I know we have had discussion touching on this before. But post vacation and looking on this charter again I think we need to have some additional discussion of the goals and how the charter describes them in relation to encoder sub-streams and identification of what is encapsulated.

In regards to the below:

This working group 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
working group will, however, define how SFrame interacts with RTP (e.g., with
regard to packetization, depacketization, and recovery algorithms) to ensure
that it can be used in environments such as WebRTC.

I think there exist a conflict in the above paragraph in relation to stated goals of the work. With the following earlier sentence: " It may also be
desirable to encrypt units of intermediate size (e.g., H.264 NALUs or AV1 OBUs) to allow partial frames to be usable." in mind creating an RTP payload format that is capable of carrying SFRAMEs that contains these units will require some interaction with the signalling. Even without these sub-stream SFRAMEs there exist a description capability that needs to exist in an RTP payload format for the end-consumer to correctly be able to route the protected data after decapsulation and that the end-point having that capability. 

If the goal here when it comes to RTP is simply to be able to treat SFRAME as CODEC in WebRTC and thus use WebRTC InsertableStreams as a receiver of the decrypted media ADUs. Require the use of the WebRTC application to have a proprietary signalling to know what this ADU is and then route it to a media decoder? I can see that working in the WebRTC only context. However, I would prefer if some thought was spent on at least having a model for what information may be needed to be able to handle the media streams. Considering RFC 7656 (https://datatracker.ietf.org/doc/rfc7656/) and the work that was needed for us to up-level how RTP worked and even discuss this so that we understood each other. I think SFRAME needs to discuss how it is going to handle identification of the data encapsulated by SFRAMEs for media. A single media source can be encoded in multiple formats. Each format may produce one or more sub-streams of encoding for scalability or robustness and this needs to conveyed.

So looking at the above challenges in the context of SFRAME over RTP. So a possibility here is to say that the SSRC represents either just a media source. The RTP payload format provides only fragmentation of the SFRAME across multiple RTP packets and the RTP timestamp can be used to indicate its belonging in the timeline of the encoding. That puts a lot of the identification on the SFRAME layer, but its minimizes the signalling interactions related to RTP. However it creates limitation about what the SFU can do, especially when it comes to repair. Switching can be done based on Frame-marker extension header. However, layer related loss detection becomes impossible without additional information, or use of multiple SSRCs.

Thus, I think the charter as currently written are uncertain if it can be executed on with stated goals.
2020-09-07
00-00 Magnus Westerlund
[Ballot comment]

* Information to form a unique nonce within the scope of the key

Is this really "Information to form a" the best formulation. …
[Ballot comment]

* Information to form a unique nonce within the scope of the key

Is this really "Information to form a" the best formulation. I am uncertain if the goal is to have a specification for how to generate unique Nonce values within the context of a particular key, or if it is related to which information sources that should be used when creating a nonce?
2020-09-07
00-00 Magnus Westerlund [Ballot Position Update] New position, Block, has been recorded for Magnus Westerlund
2020-09-02
00-00 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2020-09-01
00-00 Murray Kucherawy [Ballot Position Update] New position, Yes, has been recorded for Murray Kucherawy
2020-08-31
00-00 Martin Duke [Ballot Position Update] Position for Martin Duke has been changed to No Objection from Yes
2020-08-31
00-00 Martin Duke [Ballot Position Update] New position, Yes, has been recorded for Martin Duke
2020-08-30
00-00 Cindy Morgan Placed on agenda for telechat - 2020-09-10
2020-08-29
00-00 Murray Kucherawy WG action text was changed
2020-08-29
00-00 Murray Kucherawy WG review text was changed
2020-08-29
00-00 Murray Kucherawy WG review text was changed
2020-08-29
00-00 Murray Kucherawy Created "Ready for external review" ballot
2020-08-29
00-00 Murray Kucherawy State changed to Start Chartering/Rechartering (Internal Steering Group/IAB Review) from Draft Charter
2020-08-19
00-00 Barry Leiba Notification list changed to dispatch@ietf.org
2020-08-19
00-00 Barry Leiba Added charter milestone "Submit SFrame specification to IESG (Standards Track)", due June 2021
2020-08-19
00-00 Barry Leiba Initial review time expires 2020-08-26
2020-08-19
00-00 Barry Leiba State changed to Draft Charter from Not currently under review
2020-08-19
00-00 Barry Leiba New version available: charter-ietf-sframe-00-00.txt