Skip to main content

Secure Frame (SFrame)
draft-ietf-sframe-enc-09

Revision differences

Document history

Date Rev. By Action
2024-06-24
09 (System) RFC Editor state changed to AUTH48
2024-06-12
09 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2024-04-30
09 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2024-04-29
09 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2024-04-29
09 (System) IANA Action state changed to In Progress from Waiting on Authors
2024-04-12
09 (System) IANA Action state changed to Waiting on Authors from In Progress
2024-04-05
09 (System) RFC Editor state changed to EDIT
2024-04-05
09 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2024-04-05
09 (System) Announcement was received by RFC Editor
2024-04-05
09 (System) IANA Action state changed to In Progress
2024-04-05
09 (System) Removed all action holders (IESG state changed)
2024-04-05
09 Jenny Bui IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2024-04-05
09 Jenny Bui IESG has approved the document
2024-04-05
09 Jenny Bui Closed "Approve" ballot
2024-04-05
09 Jenny Bui Ballot approval text was generated
2024-04-04
09 Murray Kucherawy IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2024-04-04
09 Richard Barnes New version available: draft-ietf-sframe-enc-09.txt
2024-04-04
09 (System) New version approved
2024-04-04
09 (System) Request for posting confirmation emailed to previous authors: Emad Omara , Justin Uberti , Richard Barnes , Sergio Murillo , Youenn Fablet
2024-04-04
09 Richard Barnes Uploaded new revision
2024-04-04
08 (System) Changed action holders to Murray Kucherawy (IESG state changed)
2024-04-04
08 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-04-04
08 Richard Barnes New version available: draft-ietf-sframe-enc-08.txt
2024-04-04
08 (System) New version approved
2024-04-04
08 (System) Request for posting confirmation emailed to previous authors: Emad Omara , Justin Uberti , Richard Barnes , Sergio Murillo , Youenn Fablet
2024-04-04
08 Richard Barnes Uploaded new revision
2024-04-04
07 (System) Removed all action holders (IESG state changed)
2024-04-04
07 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation::Revised I-D Needed
2024-04-04
07 Paul Wouters [Ballot comment]
Thanks for the discussion on my raised issues. I've updated my ballot to Yes
2024-04-04
07 Paul Wouters [Ballot Position Update] Position for Paul Wouters has been changed to Yes from Discuss
2024-04-04
07 (System) Changed action holders to Richard Barnes, Justin Uberti, Youenn Fablet, Sergio Garcia Murillo, Emad Omara (IESG state changed)
2024-04-04
07 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2024-04-04
07 Paul Wouters
[Ballot discuss]
I have some questions that are likely easily answered and more indicative of my lack of experience in streaming infrastructure.

1) KID and …
[Ballot discuss]
I have some questions that are likely easily answered and more indicative of my lack of experience in streaming infrastructure.

1) KID and CTR encoding

Is there really much to be gained from the SFrame Header KID and CTR encoding for small values? For example an audio or video stream
would almost immediately require the "extended encoding" for the CTR? I find it difficult to see the advantage of this added complexity.

2) Tag size

What is the real gain of allowing shorter authentication tags? Even the document itself states:

        Nonetheless, without these mitigations, an application that
        makes use of short tags will be at heightened risk of forgery
        attacks. In many cases, it is simpler to use full-size tags and
        tolerate slightly higher bandwidth usage rather than add the
        additional defenses necessary to safely use short tags.

Why not simplify on just 1 tag size?


3) IANA Considerations

Have you considered splitting the ciphersuites into a part that
requires standards action and a part that is specification required?

Related, have you considered using a RECOMMENDED column for ciphersuites,
where a RECOMMENDED=y can only be done via standards action?
2024-04-04
07 Paul Wouters [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters
2024-04-04
07 Éric Vyncke
[Ballot comment]
Thank you for the work done in this I-D. It is *really* well-written and I love the neat SVG graphics!  Also a good …
[Ballot comment]
Thank you for the work done in this I-D. It is *really* well-written and I love the neat SVG graphics!  Also a good idea to have test data.

While I am not familiar at all about MLS, I wonder whether only using E bits of the epoch in section 5.2 does not open a window for replay attack? Should there be some guidance for the minimum amount of E bits ?

Thanks as well to Suresh Krishnan for his int-dir review at: https://datatracker.ietf.org/doc/review-ietf-sframe-enc-07-intdir-telechat-krishnan-2024-03-29/ and I have read Richard's reply.

Nits:

- be consistent for "hop-by-hop" or "hop by hop"
- expand RTX (and possibly FEC) at first use
- perhaps define 'frame' (I understood it like a MPEG frame but could be wrong)
2024-04-04
07 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2024-04-04
07 Zaheduzzaman Sarker [Ballot comment]
Thanks for working on this specification.
2024-04-04
07 Zaheduzzaman Sarker [Ballot Position Update] New position, Yes, has been recorded for Zaheduzzaman Sarker
2024-04-03
07 John Scudder
[Ballot comment]
Thanks for this document. To the extent I’m qualified to review it, I found it clear, comprehensive, and readable. I have a minor …
[Ballot comment]
Thanks for this document. To the extent I’m qualified to review it, I found it clear, comprehensive, and readable. I have a minor comment and a trivial question.

Comment:

“Invalid ciphertexts SHOULD be discarded in a way that is indistinguishable (to an external observer) from having processed a valid ciphertext.”

This might be clear to someone within your ecosystem, but I wonder what exactly is meant by “external” here. I infer it means an observer without any access to a system that’s participating in the conference, because otherwise, I don’t see how this requirement could be met (consider the case where the discarded ciphertext is a keyframe, for example).

Whether this calls for clarification or not is up to you.

Question:

I also wonder as to the practical value of the compressed CTR representation — I would have imagined that most use cases would emit more than 8 plaintexts, and for that matter, if there are 8 or fewer plaintexts to be emitted over the lifetime of the KID, the application is so low-volume that maybe the optimization doesn’t buy you much as compared to, say, adding another bit to the compressed KID field.

But this is just idle curiosity, even if the answer was “yeah, it’s not that useful” I wouldn’t advocate changing the encoding at this late date.
2024-04-03
07 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2024-04-02
07 Roman Danyliw
[Ballot comment]
Thank you to Linda Dunbar for the GENART review.  I reviewed this document for GEN area issues.

** Section 8.1.  Per the SFrame …
[Ballot comment]
Thank you to Linda Dunbar for the GENART review.  I reviewed this document for GEN area issues.

** Section 8.1.  Per the SFrame Cipher Suites registry, did the working group consider adding another column to the registry to capture the whether the IETF recommends the use of a given ciphersuite?  Consider the definition of a “Recommended” column in the TLS Ciphersuites and COSE Algorithms registries:

-- https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
-- https://www.iana.org/assignments/cose/cose.xhtml#algorithms

Could such a Recommendation column be added here?  It helps readers of the registry quickly understand which registrations have an IETF endorsement, while still making it easy to add code points.
2024-04-02
07 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2024-04-02
07 Deb Cooley
[Ballot comment]
Thanks to Carl Wallace for his review.  I checked some of his nits, and they appear to be addressed, even though there was …
[Ballot 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.)
2024-04-02
07 Deb Cooley [Ballot Position Update] New position, No Objection, has been recorded for Deb Cooley
2024-04-02
07 Warren Kumari
[Ballot comment]
Thank you for this document -- I found it a fascinating read.

I am balloting NoObj, but have some nits to offer to …
[Ballot comment]
Thank you for this document -- I found it a fascinating read.

I am balloting NoObj, but have some nits to offer to further improve it.

1: 1.  Hop-by-hop (HBH) encryption of media, metadata, and feedback messages between the the endpoints and SFU
s/the the/the/

2: "the receiving client collects all the fragments of the ciphertext, using an appropriate sequencing and start/end markers in the transport. "
s/an// (I think!)

3: ""_80" indicates a eighty-bit tag,"
s/a/an/

4: Key IDs in this scheme have two parts, a "key generation" and a "ratchet step".
s/,/:/

5: "Ratcheting the key forward is useful when adding new receivers to an SFrame-based interaction, since it assures that the new receivers can't decrypt any media encrypted before they were added."
s/assures/ensures/ (I think...?!)

6: Such a brute-force attack will have an expected sucess rate of the following form:
s/sucess/success/
2024-04-02
07 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2024-04-01
07 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2024-03-30
07 Linda Dunbar Request for Last Call review by GENART Completed: Ready. Reviewer: Linda Dunbar. Sent review to list.
2024-03-29
07 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2024-03-29
07 Suresh Krishnan Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Suresh Krishnan. Sent review to list.
2024-03-29
07 Gunter Van de Velde [Ballot comment]
idnit:
s/sucess/success/
2024-03-29
07 Gunter Van de Velde [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde
2024-03-28
07 Orie Steele
[Ballot comment]
Thanks to Valery Smyslov for the ART-ART review. It appears all feedback has been addressed.
Thanks to Martin Thomson for the Shepherd writeup... …
[Ballot comment]
Thanks to Valery Smyslov for the ART-ART review. It appears all feedback has been addressed.
Thanks to Martin Thomson for the Shepherd writeup... Noting that it is partially complete.


"""
expected sucess rate of the following form
"""

Typo, see https://github.com/sframe-wg/sframe/pull/189
2024-03-28
07 Orie Steele Ballot comment text updated for Orie Steele
2024-03-27
07 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2024-03-25
07 Orie Steele
[Ballot comment]
Thanks to Valery Smyslov for the ART-ART review. It appears all feedback has been addressed.
Thanks to Martin Thomson for the Shepherd writeup... …
[Ballot comment]
Thanks to Valery Smyslov for the ART-ART review. It appears all feedback has been addressed.
Thanks to Martin Thomson for the Shepherd writeup... Noting that it is partially complete, and missing confirmation of IPR.


"""
expected sucess rate of the following form
"""

Typo, see https://github.com/sframe-wg/sframe/pull/189
2024-03-25
07 Orie Steele Ballot comment text updated for Orie Steele
2024-03-25
07 Orie Steele [Ballot Position Update] Position for Orie Steele has been changed to Yes from No Objection
2024-03-25
07 Orie Steele
[Ballot comment]
Thanks to Valery Smyslov for the ART-ART review. It appears all feedback has been addressed.
Thanks for Martin Thomson for the Shepherd writeup... …
[Ballot comment]
Thanks to Valery Smyslov for the ART-ART review. It appears all feedback has been addressed.
Thanks for Martin Thomson for the Shepherd writeup... Noting that it is partially complete, and missing confirmation of IPR.


"""
expected sucess rate of the following form
"""

Typo, see https://github.com/sframe-wg/sframe/pull/189
2024-03-25
07 Orie Steele Ballot comment text updated for Orie Steele
2024-03-25
07 Orie Steele [Ballot comment]
"""
expected sucess rate of the following form
"""

Typo, see https://github.com/sframe-wg/sframe/pull/189
2024-03-25
07 Orie Steele [Ballot Position Update] New position, No Objection, has been recorded for Orie Steele
2024-03-05
07 Bernie Volz Request for Telechat review by INTDIR is assigned to Suresh Krishnan
2024-03-03
07 Éric Vyncke Requested Telechat review by INTDIR
2024-02-29
07 Cindy Morgan Placed on agenda for telechat - 2024-04-04
2024-02-29
07 Murray Kucherawy Ballot has been issued
2024-02-29
07 Murray Kucherawy [Ballot Position Update] New position, Yes, has been recorded for Murray Kucherawy
2024-02-29
07 Murray Kucherawy Created "Approve" ballot
2024-02-29
07 Murray Kucherawy IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2024-02-29
07 Murray Kucherawy Ballot writeup was changed
2024-02-29
07 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2024-02-29
07 Richard Barnes New version available: draft-ietf-sframe-enc-07.txt
2024-02-29
07 (System) New version approved
2024-02-29
07 (System) Request for posting confirmation emailed to previous authors: Emad Omara , Justin Uberti , Richard Barnes , Sergio Murillo , Youenn Fablet
2024-02-29
07 Richard Barnes Uploaded new revision
2024-02-27
06 Carlos Pignataro Closed request for Last Call review by OPSDIR with state 'Overtaken by Events'
2024-02-27
06 Carlos Pignataro Assignment of request for Last Call review by OPSDIR to Linda Dunbar was marked no-response
2024-02-17
06 Carl Wallace Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Carl Wallace. Sent review to list.
2024-02-15
06 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2024-02-14
06 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2024-02-13
06 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2024-02-13
06 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-sframe-enc-06. If any part of this review is inaccurate, please let us know.

IANA …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-sframe-enc-06. If any part of this review is inaccurate, please let us know.

IANA has a question about the second action requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, a new registry group is to be created on the IANA Matrix located at:

https://www.iana.org/protocols

The new registry group will be called SFrame and will have a reference of [ RFC-to-be ].

Second, a new registry will be created called Sframe Cipher Suites. The new registry will be located in the registry group created above. The values in the registry range from 0x0000 to 0xFFFF. The new registry is managed via Specification Required as defined in RFC8126.

There are initial registrations in the new registry as follows:

Value Name Reference
-----+-----+-----------
0x0001 AES_128_CTR_HMAC_SHA256_80 [ RFC-to-be ]
0x0002 AES_128_CTR_HMAC_SHA256_64 [ RFC-to-be ]
0x0003 AES_128_CTR_HMAC_SHA256_32 [ RFC-to-be ]
0x0004 AES_128_GCM_SHA256_128 [ RFC-to-be ]
0x0005 AES_256_GCM_SHA512_128 [ RFC-to-be ]
0x0006 - 0xEFFF Unassigned
0xF000 - 0xFFFF Reserved for private use [ RFC-to-be ]

IANA Question --> Is the value 0x0000 reserved or unassigned?

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist
2024-02-12
06 Valery Smyslov Request for Last Call review by ARTART Completed: Ready with Issues. Reviewer: Valery Smyslov. Sent review to list.
2024-02-12
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Linda Dunbar
2024-02-12
06 Tim Chown Assignment of request for Last Call review by OPSDIR to Tim Chown was rejected
2024-02-07
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Chown
2024-02-06
06 Barry Leiba Request for Last Call review by ARTART is assigned to Valery Smyslov
2024-02-02
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Carl Wallace
2024-02-01
06 Jean Mahoney Request for Last Call review by GENART is assigned to Linda Dunbar
2024-02-01
06 Cindy Morgan IANA Review state changed to IANA - Review Needed
2024-02-01
06 Cindy Morgan
The following Last Call announcement was sent out (ends 2024-02-15):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sframe-enc@ietf.org, mt@lowentropy.net, sframe-chairs@ietf.org, sframe@ietf.org, superuser@gmail.com …
The following Last Call announcement was sent out (ends 2024-02-15):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sframe-enc@ietf.org, mt@lowentropy.net, sframe-chairs@ietf.org, sframe@ietf.org, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Secure Frame (SFrame)) to Proposed Standard


The IESG has received a request from the Secure Media Frames WG (sframe) to
consider the following document: - 'Secure Frame (SFrame)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-02-15. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes the Secure Frame (SFrame) end-to-end
  encryption and authentication mechanism for media frames in a
  multiparty conference call, in which central media servers (selective
  forwarding units or SFUs) can access the media metadata needed to
  make forwarding decisions without having access to the actual media.

  The proposed mechanism differs from the Secure Real-Time Protocol
  (SRTP) in that it is independent of RTP (thus compatible with non-RTP
  media transport) and can be applied to whole media frames in order to
  be more bandwidth efficient.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sframe-enc/



No IPR declarations have been submitted directly on this I-D.




2024-02-01
06 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2024-02-01
06 Cindy Morgan Last call announcement was generated
2024-01-31
06 Murray Kucherawy Last call was requested
2024-01-31
06 Murray Kucherawy Ballot approval text was generated
2024-01-31
06 Murray Kucherawy Ballot writeup was generated
2024-01-31
06 Murray Kucherawy IESG state changed to Last Call Requested from AD Evaluation
2024-01-31
06 Murray Kucherawy Last call announcement was generated
2023-12-06
06 Martin Thomson Adding MLS draft as input to this work.
2023-12-06
06 Martin Thomson This document now replaces draft-barnes-sframe-mls, draft-omara-sframe instead of draft-omara-sframe
2023-12-06
06 (System) Changed action holders to Murray Kucherawy (IESG state changed)
2023-12-06
06 Murray Kucherawy IESG state changed to AD Evaluation from Publication Requested
2023-12-05
06 Martin Thomson
Document writeup for draft-ietf-sframe-enc-06
Shepherd: Martin Thomson
Date: 2023-12-06


# Document History

This document is the input document that caused the formation of the SFrame …
Document writeup for draft-ietf-sframe-enc-06
Shepherd: Martin Thomson
Date: 2023-12-06


# Document History

This document is the input document that caused the formation of the SFrame
working group.  It is substantially the same as that original input on a
technical level, though many aspects of that design have been tested in the
working group. The editorial quality is significantly improved and more robust
security and deployment considerations are now present.  The one major addition
was the inclusion of a concrete usage of MLS for key management, which was
originally in a separate draft.

This work spent a long time without a lot activity, interspersed with short
bursts of high productivity.  The WG chairs believe that sufficient input has
been received despite this.

Implementations and deployments exist.  Test vectors are included and are
produced and checked by an automated system.

# Reviews

This document includes a very straightforward integration of AEAD and HKDF.
Careful security review from outside of the working group will be helpful, but
this shepherd believes that this has a low risk profile due to the extreme lack
of novelty.  There is no formal analysis.

# Checks

The document is clear and precise.  The design is sensible and appropriately
scoped.

Checked: Status (std), IPR (checks in progress), issues, idnits (what a trash
fire of a program), references (no downrefs, no unfinished work), registries.

# Registry Experts

A new registry is established for ciphersuites.  This will need experts.  I
recommend that this include all of the draft authors (checking with authors in
progress).
2023-12-05
06 Martin Thomson Responsible AD changed to Murray Kucherawy
2023-12-05
06 Martin Thomson IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2023-12-05
06 Martin Thomson IESG state changed to Publication Requested from I-D Exists
2023-12-05
06 Martin Thomson Document is now in IESG state Publication Requested
2023-12-05
06 Martin Thomson
Document writeup for draft-ietf-sframe-enc-06
Shepherd: Martin Thomson
Date: 2023-12-06


# Document History

This document is the input document that caused the formation of the SFrame …
Document writeup for draft-ietf-sframe-enc-06
Shepherd: Martin Thomson
Date: 2023-12-06


# Document History

This document is the input document that caused the formation of the SFrame
working group.  It is substantially the same as that original input on a
technical level, though many aspects of that design have been tested in the
working group. The editorial quality is significantly improved and more robust
security and deployment considerations are now present.  The one major addition
was the inclusion of a concrete usage of MLS for key management, which was
originally in a separate draft.

This work spent a long time without a lot activity, interspersed with short
bursts of high productivity.  The WG chairs believe that sufficient input has
been received despite this.

Implementations and deployments exist.  Test vectors are included and are
produced and checked by an automated system.

# Reviews

This document includes a very straightforward integration of AEAD and HKDF.
Careful security review from outside of the working group will be helpful, but
this shepherd believes that this has a low risk profile due to the extreme lack
of novelty.  There is no formal analysis.

# Checks

The document is clear and precise.  The design is sensible and appropriately
scoped.

Checked: Status (std), IPR (checks in progress), issues, idnits (what a trash
fire of a program), references (no downrefs, no unfinished work), registries.

# Registry Experts

A new registry is established for ciphersuites.  This will need experts.  I
recommend that this include all of the draft authors (checking with authors in
progress).
2023-12-05
06 Martin Thomson Notification list changed to mt@lowentropy.net because the document shepherd was set
2023-12-05
06 Martin Thomson Document shepherd changed to Martin Thomson
2023-12-05
06 Richard Barnes New version available: draft-ietf-sframe-enc-06.txt
2023-12-05
06 (System) New version approved
2023-12-05
06 (System) Request for posting confirmation emailed to previous authors: Emad Omara , Justin Uberti , Richard Barnes , Sergio Murillo , Youenn Fablet
2023-12-05
06 Richard Barnes Uploaded new revision
2023-12-04
05 Martin Thomson Working on write-up for IESG
2023-12-04
05 Martin Thomson IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2023-12-04
05 Richard Barnes New version available: draft-ietf-sframe-enc-05.txt
2023-12-04
05 Richard Barnes New version approved
2023-12-04
05 (System) Request for posting confirmation emailed to previous authors: Emad Omara , Justin Uberti , Richard Barnes , Sergio Murillo , Youenn Fablet
2023-12-04
05 Richard Barnes Uploaded new revision
2023-10-22
04 Martin Thomson IETF WG state changed to In WG Last Call from WG Document
2023-10-22
04 Martin Thomson Changed consensus to Yes from Unknown
2023-10-22
04 Martin Thomson Intended Status changed to Proposed Standard from None
2023-10-22
04 Richard Barnes New version available: draft-ietf-sframe-enc-04.txt
2023-10-22
04 (System) New version approved
2023-10-22
04 (System) Request for posting confirmation emailed to previous authors: Emad Omara , Justin Uberti , Richard Barnes , Sergio Murillo , Youenn Fablet
2023-10-22
04 Richard Barnes Uploaded new revision
2023-08-04
03 Richard Barnes New version available: draft-ietf-sframe-enc-03.txt
2023-08-04
03 Richard Barnes New version approved
2023-08-04
03 (System) Request for posting confirmation emailed to previous authors: Emad Omara , Justin Uberti , Richard Barnes , Sergio Murillo , Youenn Fablet
2023-08-04
03 Richard Barnes Uploaded new revision
2023-07-10
02 Richard Barnes New version available: draft-ietf-sframe-enc-02.txt
2023-07-10
02 (System) New version approved
2023-07-10
02 (System) Request for posting confirmation emailed to previous authors: Emad Omara , Justin Uberti , Richard Barnes , Sergio Murillo , Youenn Fablet
2023-07-10
02 Richard Barnes Uploaded new revision
2023-07-10
02 (System) Request for posting confirmation emailed to previous authors: Emad Omara , Justin Uberti , Richard Barnes , Sergio Murillo , Youenn Fablet
2023-07-10
02 Richard Barnes Uploaded new revision
2023-05-23
01 Bernard Aboba Added to session: interim-2023-avtcore-02
2023-05-23
01 Bernard Aboba Removed from session: interim-2023-avtcore-02
2023-03-29
01 Bernard Aboba Added to session: interim-2023-avtcore-02
2023-03-27
01 Bernard Aboba Added to session: IETF-116: avtcore  Tue-0400
2023-03-13
01 Richard Barnes New version available: draft-ietf-sframe-enc-01.txt
2023-03-13
01 (System) New version approved
2023-03-13
01 (System) Request for posting confirmation emailed to previous authors: Emad Omara , Justin Uberti , Richard Barnes , Sergio Murillo , Youenn Fablet
2023-03-13
01 Richard Barnes Uploaded new revision
2023-02-13
00 Martin Thomson Changed document external resources from: None to:

github_org https://github.com/sframe-wg
github_repo https://github.com/sframe-wg/sframe
2023-02-13
00 Martin Thomson This document now replaces draft-omara-sframe instead of None
2023-01-30
00 (System) Document has expired
2022-07-29
00 Emad Omara New version available: draft-ietf-sframe-enc-00.txt
2022-07-29
00 Martin Thomson WG -00 approved
2022-07-29
00 Emad Omara Set submitter to "Emad Omara ", replaces to (none) and sent approval email to group chairs: sframe-chairs@ietf.org
2022-07-29
00 Emad Omara Uploaded new revision