Completely Encrypting RTP Header Extensions and Contributing Sources
RFC 9335

Received changes through RFC Editor sync (created alias RFC 9335, changed abstract to 'While the Secure Real-time Transport Protocol (SRTP) provides confidentiality for the contents of a media packet, a significant amount of metadata is left unprotected, including RTP header extensions and contributing sources (CSRCs). However, this data can be moderately sensitive in many applications. While there have been previous attempts to protect this data, they have had limited deployment, due to complexity as well as technical limitations.

This document updates RFC 3711, the SRTP specification, and defines Cryptex as a new mechanism that completely encrypts header extensions and CSRCs and uses simpler Session Description Protocol (SDP) signaling with the goal of facilitating deployment.', changed pages to 21, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2023-01-25, changed IESG state to RFC Published, created updates relation between draft-ietf-avtcore-cryptex and RFC 3711)

[Ballot comment]
Thanks for addressing my DISCUSS in -08. I have changed my ballot to No Objection.

Old DISCUSS:


Thanks for this document. It is clear, and I appreciate reading the rationale of the proposed solution. Just one discuss item:

  Peers MAY negotiate both Cryptex and the header extension mechanism
  defined in [RFC6904] via signaling, and if both mechanisms are
  supported, either one can be used for any given packet.  However, if
  a packet is encrypted with Cryptex, it MUST NOT also use [RFC6904]
  header extension encryption, and vice versa.

Why this complexity? Based on the Section 1, Cryptex is much more preferred.
Why allow "either one can be used for any given packet" instead of saying
if both are negotiated, Cryptex SHOULD be used? Or why not stronger, if
both peers support Cryptex, RFC6904 SHOULD NOT (MUST NOT?) be used?

COMMENTS:



The Shepherds write-up with respect to IPR shows two authors confirming they
have filed "all required disclosures" but does not list whether this
means "there are non", "there are some, compatible with IETF" or that
there is "disclosed, incompatible with IETF". The Shepherds write up
does state no disclosures are filed. I find the two authors' response a
bit odd.

Section 1.2 describes a problem of "using a few more bytes", but how is that
a real problem? Does it really matter? The other reasons stated seem
real issues to me but the "few more bytes" seems fairly harmless?

        we felt

Who or what is "we"? Probably rewrite to "It was considered" or something?

  Alternatively, if the implementation considers the use of this
  specification mandatory and the "defined by profile" field does not
  match one of the values defined above, it SHOULD stop the processing
  of the RTP packet and report an error for the RTP stream.

Why is this not a MUST stop ? If it is mandatory, what is an example
where it can continue processing an RTP packet without the mandatory requirement?

It seems Section 3 could be just a last paragraph of the Introduction?

Nits:

Section 1.1 first line misses "(SRTP)" acronym

CSRC not expanded before first use.

Section 1.2  "RFC6904" is not properly linked

Section 4's title could be improved, eg "Signaling of Cryptex Support"

Section 4's opening line could be simplified eg:

  Cryptex support is indicated via the new "a=cryptex" Session
  Description Protocol (SDP) attribute.

SDP not expanded on first use

BUNDLE is not expanded (or linked to a reference) on first use.

[RFC8285] in Section 5 is not a proper link

I personally dislike "+-+-+-+-+-+-+-+-+-+-+-+-+-+-+" and prefer the
less christmas tree "+------+----------+" style diagram :)

[Ballot discuss]
# GEN AD review of draft-ietf-avtcore-cryptex-06

CC @larseggert

Thanks to Linda Dunbar for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/OSDyO_tiu5StDZyyJjwRP-Nvj-M).

## Discuss

### IANA

This document seems to have unresolved IANA issues. Holding a DISCUSS
until we can confirm on the telechat that a resolution is in progress.

[Ballot comment]
## Comments

### Section 1.2, paragraph 1
```
    [RFC6904] was proposed in 2013 as a solution to the problem of
    unprotected header extension values.  However, it has not seen
    significant adoption, and has a few technical shortcomings.
```
Would it be time to deprecate 6904? (Also see Paul's DISCUSS and Alavaro's
comment.)

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `master`; alternatives might be `active`, `central`, `initiator`,
  `leader`, `main`, `orchestrator`, `parent`, `primary`, `server`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Section 5.1, paragraph 1
```
    When the mechanism defined by this specification has been negotiated,
    sending a RTP packet that has any CSRCs or contains any {RFC8285}}
    header extensions follows the steps below.  This mechanism MUST NOT
    be used with header extensions other than the [RFC8285] variety.
```
Likely Markdown nit: {RFC8285}}

### Outdated references

Reference `[RFC4566]` to `RFC4566`, which was obsoleted by `RFC8866` (this may
be on purpose).

### Grammar/style

#### Section 5, paragraph 0
```
fication has been negotiated, sending a RTP packet that has any CSRCs or cont
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 5.1, paragraph 4
```
ecryption Procedure, and passed to the the next layer to process the packet a
                                  ^^^^^^^
```
Possible typo: you repeated a word.

#### Section 6.2, paragraph 9
```
ence number and SSRC identifier. Accordingly these values are also not encryp
                                ^^^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Accordingly".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot discuss]
This document seems to have unresolved IANA issues. Holding a DISCUSS
until we can confirm on the telechat that a resolution is in progress.

[Ballot comment]
Thanks to Linda Dunbar for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/OSDyO_tiu5StDZyyJjwRP-Nvj-M).

-------------------------------------------------------------------------------
COMMENT
-------------------------------------------------------------------------------

Section 1.2, paragraph 1
>    [RFC6904] was proposed in 2013 as a solution to the problem of
>    unprotected header extension values.  However, it has not seen
>    significant adoption, and has a few technical shortcomings.


Would it be time to deprecate 6904? (Also see Paul's DISCUSS and Alavaro's
comment.)

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "master"; alternatives might be "active", "central", "initiator",
  "leader", "main", "orchestrator", "parent", "primary", "server"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 5.1, paragraph 1
>    When the mechanism defined by this specification has been negotiated,
>    sending a RTP packet that has any CSRCs or contains any {RFC8285}}
>    header extensions follows the steps below.  This mechanism MUST NOT
>    be used with header extensions other than the [RFC8285] variety.


Likely Markdown nit: {RFC8285}}

Reference [RFC4566] to RFC4566, which was obsoleted by RFC8866 (this may be on
purpose).

Section 5, paragraph 0
> fication has been negotiated, sending a RTP packet that has any CSRCs or cont
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 5.1, paragraph 4
> ecryption Procedure, and passed to the the next layer to process the packet a
>                                    ^^^^^^^
Possible typo: you repeated a word.

Section 6.2, paragraph 9
> ence number and SSRC identifier. Accordingly these values are also not encryp
>                                  ^^^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Accordingly".

[Ballot comment]
Thanks for working on this important specification. I just wish if we could provide more stronger specification and don't allow the mix of cryptex with other not so secure exiting solutions.

I have some comments/suggestions/questions -

- the shepherd's write-up says there is not IPR declarations but https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-avtcore-cryptex return two hits on IPR declarations. The write up should be updated, was the WG not aware of these IPRs?

- section 1.1 : it says -
               
        "Accordingly, these identifiers can be considered a fingerprinting issue."

    is there any analysis of this claim that can be referred to?"

- section 1.3 : it says -

        "While we considered possible solutions that would have encrypted more of the RTP header (e.g., the number of CSRCs), we felt the inability to parse the resultant packets with current tools, as well as additional complexity incurred, outweighed the slight improvement in confidentiality"

    if I have understood it correctly, I would suggest to rewrite this to something like -

        While considering the possible solutions that would have encrypted more of the RTP header (e.g., the number of CSRCs), lack of support on current tools was inevitable and the additional complexity outweighed the slight improvement in confidentiality by fixing previous solutions. Hence, new approach was needed to solve the described problem in section 1.1.

[Ballot comment]
Thanks for working on this important specification. I just wish if we could provide more stronger specification and don't allow the mix of cryptex with other not so secure exiting solutions.

I have some comments/suggestions -

- the shepherd's write-up says there is not IPR declarations but https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-avtcore-cryptex return two hits on IPR declarations. The write up should be updated, was the WG not aware of these IPRs?

- section 1.1 : it says -
               
        "Accordingly, these identifiers can be considered a fingerprinting issue."

    is there any analysis of this claim that can be referred to?"

- section 1.3 : it says -

        "While we considered possible solutions that would have encrypted more of the RTP header (e.g., the number of CSRCs), we felt the inability to parse the resultant packets with current tools, as well as additional complexity incurred, outweighed the slight improvement in confidentiality"

    if I have understood it correctly, I would suggest to rewrite this to something like -

        While considering the possible solutions that would have encrypted more of the RTP header (e.g., the number of CSRCs), lack of support on current tools was inevitable and the additional complexity outweighed the slight improvement in confidentiality by fixing previous solutions. Hence, new approach was needed to solve the described problem in section 1.1.

Questions from the attribute-name expert:

Section 4, 2nd paragraph
- Why are they referencing the obsolete RFC 4566 here instead of RFC 8866 ?

Section 4, 2nd paragraph
- It says the the attribute "can be used at the session level or media level", however the IANA registration in Section 9.1 says it can only be used at the media-level. Which way is it ?

Once these are resolved, the registration is good to proceed.

[Ballot comment]
I support Paul's DISCUSS.

I believe that this document should formally Update rfc3711.  The mechanism described here is a replacement for what rfc6904 defined.  That original mechanism was tagged as formally Updating rfc3711 -- this work should also be tagged that way.

[Ballot discuss]
Thanks for this document. It is clear, and I appreciate reading the rationale of the proposed solution. Just one discuss item:

  Peers MAY negotiate both Cryptex and the header extension mechanism
  defined in [RFC6904] via signaling, and if both mechanisms are
  supported, either one can be used for any given packet.  However, if
  a packet is encrypted with Cryptex, it MUST NOT also use [RFC6904]
  header extension encryption, and vice versa.

Why this complexity? Based on the Section 1, Cryptex is much more preferred.
Why allow "either one can be used for any given packet" instead of saying
if both are negotiated, Cryptex SHOULD be used? Or why not stronger, if
both peers support Cryptex, RFC6904 SHOULD NOT (MUST NOT?) be used?

[Ballot comment]
The Shepherds write-up with respect to IPR shows two authors confirming they
have filed "all required disclosures" but does not list whether this
means "there are non", "there are some, compatible with IETF" or that
there is "disclosed, incompatible with IETF". The Shepherds write up
does state no disclosures are filed. I find the two authors' response a
bit odd.

Section 1.2 describes a problem of "using a few more bytes", but how is that
a real problem? Does it really matter? The other reasons stated seem
real issues to me but the "few more bytes" seems fairly harmless?

        we felt

Who or what is "we"? Probably rewrite to "It was considered" or something?

  Alternatively, if the implementation considers the use of this
  specification mandatory and the "defined by profile" field does not
  match one of the values defined above, it SHOULD stop the processing
  of the RTP packet and report an error for the RTP stream.

Why is this not a MUST stop ? If it is mandatory, what is an example
where it can continue processing an RTP packet without the mandatory requirement?

It seems Section 3 could be just a last paragraph of the Introduction?

Nits:

Section 1.1 first line misses "(SRTP)" acronym

CSRC not expanded before first use.

Section 1.2  "RFC6904" is not properly linked

Section 4's title could be improved, eg "Signaling of Cryptex Support"

Section 4's opening line could be simplified eg:

  Cryptex support is indicated via the new "a=cryptex" Session
  Description Protocol (SDP) attribute.

SDP not expanded on first use

BUNDLE is not expanded (or linked to a reference) on first use.

[RFC8285] in Section 5 is not a proper link

I personally dislike "+-+-+-+-+-+-+-+-+-+-+-+-+-+-+" and prefer the
less christmas tree "+------+----------+" style diagram :)

[Ballot discuss]
I’m having trouble understanding the relationship between this work and SRTP without making assumptions.  Section 1.3 notes that there is a design goal to build on top of SRTP and to have simple SRTP interactions.  Section 3 also says the design goal is to “reuse the existing SRTP framework.”  Finally, Section 6.2 and 6.3 says ”[t]he encryption (or decryption) procedure is identical to that of [RFC3711] except for the Encrypted Portion of the SRTP packet.”

I believe the correct read is that “do everything from SRTP unless noted as different here”.  However, saying “encryption and description procedures" per Sections 6.2/6.3 doesn’t capture that for me.  This leaves open questions about key management, establish and maintaining state for cryptographic contexts, MTI algorithms, etc.

The text would benefit from being explicit on what behavior “a=cryptex” behavior reuses from SRTP.  I don’t believe that changes any of the expected core mechanics.

[Ballot comment]
Thank you to Rifaat Shekh-Yusef for the SECDIR review.

** Section 6.2.  What does the notation “_4*CC_ bytes of the ciphertext …” mean?

** Section 6.2.

Implementations can rearrange a packet so that the AAD and plaintext
  are contiguous by swapping the order of the extension header and the
  CSRC identifiers, resulting in an intermediate representation of the
  form shown in Figure 2.

Where would this intermediate representation be used?  To double check, this would not be put on the wire?

** Section 8.  On MTI/optional/default transforms, does this document want to change anything from what was said in RFC3711? 

-- Should something be said about AES-GCM per RFC7714, especially since it was listed as an example.

-- Assuming this document inherits the MTI transforms for SRTP, please explicitly call out the dangers using NULL transform.

** Section 8.  Does any subset of the Security Considerations of RFC3711 apply here?

** A.1.  Cite AES-CTR per RFC3711.

** A.2.  Cite AES-GCM per RFC7714. 

Nits
** Section 5.1.  Typo.  There is a markdown typo of “{RFC8285}}” (i.e., single open brace) which is preventing the rendering this reference correctly in the first sentence.

** Section 5.2. Typo. s/the the/the/

[Ballot comment]
Thank you for writing this document; like Rob I'm far from an RTP expert, but I also found it readable and useful.



I do have a question, as well as some nits to try and make if even better.

Question:
"[RFC8285] defines two values for the "defined by profile" field for carrying one-byte and two-byte header extensions." - RFC8285 defines 0XBEDE, and has a cute justification. This document defines 0xCODE and 0XC2DE... but it was quite hard to figure out what the *other* value that RFC8285 defined -- and that's my issue. Should this document create an IANA registry to track these? Is there already a registry? E.g: If I magically become an RTP expert and write draft-ietf-avtcode-even-more-awesome-protocol how do I know not to use any of these existing numbers?



1: "If BUNDLE is in use and the a=cryptex attribute" - in all of the other instances where you have 'a=cryptex', you have it enclosed in double-quotes. I suggest doing so here too for consistency.

2: Section 5.1: "When the mechanism defined by this specification has been negotiated, sending a RTP packet that has any CSRCs or contains any {RFC8285}} header extensions follows the steps below." - something went kablooie in your formatting / markdown / kramdown / whatever and you have an extra '}' breaking the reference...

3: I got confused when reading "Note that the 4 bytes at the start of the extension block are not encrypted, as required by [RFC8285]." - it seemed ambiguous to me. I'd suggest "Note that, as required by [RFC8285], the 4 bytes at the start of the extension block are not encrypted."

I did already mention that these are nits -- this comes from 'nitpick', which dictionary.com says is "to be excessively concerned with or critical of inconsequential details." -- feel free to ignore them :-)

[Ballot comment]
Thank you for writing this document; like Rob I'm far from an RTP expert, but I also found it readable and useful.



I do have a question, as well as some nits to try and make if even better.

Question:
"[RFC8285] defines two values for the "defined by profile" field for carrying one-byte and two-byte header extensions." - RFC8285 defines 0XBEDE, and has a cute justification. This document defines 0xCODE and 0XC2DE... but it was quite hard to figure out what the *other* value that RFC8285 defined -- and that's my issue. Should this document create an IANA registry to track these? Is there already a registry? E.g: If I magically become an RTP expert and write draft-ietf-avtcode-even-more-awesome-protocol how do I know not to use any of these existing numbers?



1: "If BUNDLE is in use and the a=cryptex attribute" - in all of the other instances where you have 'a=cryptex', you have it enclosed in double-quotes. I suggest doing so here too for consistency.

2: Section 5.1: "When the mechanism defined by this specification has been negotiated, sending a RTP packet that has any CSRCs or contains any {RFC8285}} header extensions follows the steps below." - something went kablooie in your formatting / markdown / kramdown / whatever and you have an extra '}' breaking the reference...

3: I got confused when reading "Note that the 4 bytes at the start of the extension block are not encrypted, as required by [RFC8285]." - it seemed ambiguous to me. I'd suggest "Note that, as required by [RFC8285], the 4 bytes at the start of the extension block are not encrypted."

I did already mention that these are nits -- this comes from 'nitpick', which dictionary.com says is "to be excessively concerned with or critical of inconsequential details." -- feel free to ignore them at will :-)

[Ballot comment]
Hi,

I don't know RTP at all, but found that document very clear and easy to read, so thank you for that.

Only one trivial comment:

  If the packet contains solely one-byte extension ids, the 16-bit RTP
  header extension tag MUST be set to 0xC0DE to indicate that the
  encryption has been applied, and the one-byte framing is being used.
  If the packet contains only two-byte extension ids, the header
  extension tag MUST be set to 0xC2DE to indicate encryption has been
  applied, and the two-byte framing is being used.

This text doesn't say what to do if the packet contained a mix of 1 and 2 byte extension-ids.  My presumption is that this isn't allowed.  I will leave it to the authors to decide whether to clarify this, but acknowledge that it may be obvious to everyone familiar with RTP ...

Regards,
Rob

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

The IANA Functions Operator has completed its review of draft-ietf-avtcore-cryptex-05. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the media registry on the Session Description Protocol (SDP) Parameters registry page located at:

https://www.iana.org/assignments/sdp-parameters/

a new registration will be made as follows:

Type: media
SDP Name: cryptex
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action 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.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-04-05):

From: The IESG
To: IETF-Announce
CC: avt@ietf.org, avtcore-chairs@ietf.org, bernard.aboba@gmail.com, draft-ietf-avtcore-cryptex@ietf.org, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Completely Encrypting RTP Header Extensions and Contributing Sources) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Core
Maintenance WG (avtcore) to consider the following document: - 'Completely
Encrypting RTP Header Extensions and Contributing Sources'
  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 2022-04-05. 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


  While the Secure Real-time Transport Protocol (SRTP) provides
  confidentiality for the contents of a media packet, a significant
  amount of metadata is left unprotected, including RTP header
  extensions and contributing sources (CSRCs).  However, this data can
  be moderately sensitive in many applications.  While there have been
  previous attempts to protect this data, they have had limited
  deployment, due to complexity as well as technical limitations.

  This document defines Cryptex as a new mechanism that completely
  encrypts header extensions and CSRCs and uses simpler signaling with
  the goal of facilitating deployment.




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



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

Request for Publication
November 5, 2021

Document:  Completely Encrypting RTP Header Extensions and Contributing Sources
Link: https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-cryptex
Intended Status: Proposed Standard
Document Shepard: Bernard Aboba
WG: AVTCORE

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Publication as a Proposed Standard is requested.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  While the Secure Real-time Transport Protocol (SRTP) provides
  confidentiality for the contents of a media packet, a significant
  amount of metadata is left unprotected, including RTP header
  extensions and contributing sources (CSRCs). While there have been
  previous attempts to protect this data, they have had limited
  deployment, due to complexity as well as technical limitations.

  This document defines Cryptex as a new mechanism that completely
  encrypts header extensions and CSRCs and uses simpler signaling with
  the goal of facilitating deployment.

Working Group Summary:

RTP header extensions contain information that can be considered
sensitive from a privacy perspective, such as audio levels
and video content types.

RFC 6904, the initial attempt at protecting RTP header extensions,
has not been (correctly) implemented in a widespread way. RFC 6904
requires implementations to offer extensions in both encrypted/unencrypted
forms, with negotiation of encryption for each extension and resulting
SDP bloat (since every extmap requires 2 lines). The complexity has
hindered adoption of RFC 6904, with bugs in implementations such as
libsrtp going undetected for 5+ years.

Since RFC 6904 only encrypts the body of RTP header extensions, but
not the ID or length fields, even when successfully negotiated it
reveals significant information about the application. In addition
RFC 6904 does not protect RTP header fields such as contributing
sources (CSRCs).

As a result, WG consensus was that a new approach was needed.
Cryptex simplifies the deployment model by encrypting RTP
header extensions as a block as well as increasing the scope of
protection to include CSRCs.

Recent discussion with the AVTCORE WG have centered on
clarifying and reducing the complexity of Session
Description Protocol (SDP) negotiation.

Document Quality:

There are two known implementations: one in Jitsi, as well as a PR for
libsrtp which has not yet been merged. The implementations have been
checked against test vectors. A proposal for adding support within the
WebRTC API is under development.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Bernard Aboba is the Document Shepard. Responsible AD is Murray Kutcheraway.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The Document Shepard has reviewed the document as part of WGLC, and made comments that were subsequently addressed by the authors.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Recent WG discussion has centered on the SDP section, so this may deserve further scrutiny.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Additional review by the SDP Directorate may be helpful.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

Cullen Jennings: https://mailarchive.ietf.org/arch/msg/avt/zgLFBTqUca4b8ARwFJnXJOF-1Cw/
Sergio Garcia Murillo: https://mailarchive.ietf.org/arch/msg/avt/E9unITw6snUlQwtvHZYReGKk5Gg/
Justin Uberti: https://mailarchive.ietf.org/arch/msg/avt/IO_3J21OrD2wCVXFxv5zrXwg8ik/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WG has multiple participants who have been involved in the development of cryptex, as well as implementation of RFC 6904.

The consensus in favor of the document appears solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There have been no heated discussions or indication of extreme (or even mild) discontent. No threats of an appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (25 October 2021) is 10 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866)


    Summary: 1 error (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).

--------------------------------------------------------------------------------


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not appear to require any formal reviews (e.g. no MIB or YANG modules, or media type/URI type definitions). 

(13) Have all references within this document been identified as either normative or informative?

References are separated into normative and informative categories.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No changes to the status of existing RFCs.  This document does not obsolete RFC 6904.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

I have reviewed the IANA Considerations, Section 9.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No IANA registries are created.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No formal languages.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG modules.

Request for Publication
November 5, 2021

Document:  Completely Encrypting RTP Header Extensions and Contributing Sources
Link: https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-cryptex
Intended Status: Proposed Standard
Document Shepard: Bernard Aboba
WG: AVTCORE

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Publication as a Proposed Standard is requested.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  While the Secure Real-time Transport Protocol (SRTP) provides
  confidentiality for the contents of a media packet, a significant
  amount of metadata is left unprotected, including RTP header
  extensions and contributing sources (CSRCs). While there have been
  previous attempts to protect this data, they have had limited
  deployment, due to complexity as well as technical limitations.

  This document defines Cryptex as a new mechanism that completely
  encrypts header extensions and CSRCs and uses simpler signaling with
  the goal of facilitating deployment.

Working Group Summary:

RTP header extensions contain information that can be considered
sensitive from a privacy perspective, such as audio levels
and video content types.

RFC 6904, the initial attempt at protecting RTP header extensions,
has not been (correctly) implemented in a widespread way. RFC 6904
requires implementations to offer extensions in both encrypted/unencrypted
forms, with negotiation of encryption for each extension and resulting
SDP bloat (since every extmap requires 2 lines). The complexity has
hindered adoption of RFC 6904, with bugs in implementations such as
libsrtp going undetected for 5+ years.

Since RFC 6904 only encrypts the body of RTP header extensions, but
not the ID or length fields, even when successfully negotiated it
reveals significant information about the application. In addition
RFC 6904 does not protect RTP header fields such as contributing
sources (CSRCs).

As a result, WG consensus was that a new approach was needed.
Cryptex simplifies the deployment model by encrypting RTP
header extensions as a block as well as increasing the scope of
protection to include CSRCs.

Recent discussion with the AVTCORE WG have centered on
clarifying and reducing the complexity of Session
Description Protocol (SDP) negotiation.

Document Quality:

There are two known implementations: one in Jitsi, as well as a PR for
libsrtp which has not yet been merged. The implementations have been
checked against test vectors. A proposal for adding support within the
WebRTC API is under development.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Bernard Aboba is the Document Shepard. Responsible AD is Murray Kutcheraway.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The Document Shepard has reviewed the document as part of WGLC, and made comments that were subsequently addressed by the authors.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Recent WG discussion has centered on the SDP section, so this may deserve further scrutiny.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Additional review by the SDP Directorate may be helpful.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

Cullen Jennings: https://mailarchive.ietf.org/arch/msg/avt/zgLFBTqUca4b8ARwFJnXJOF-1Cw/
Sergio Garcia Murillo: https://mailarchive.ietf.org/arch/msg/avt/E9unITw6snUlQwtvHZYReGKk5Gg/
Justin Uberti: https://mailarchive.ietf.org/arch/msg/avt/IO_3J21OrD2wCVXFxv5zrXwg8ik/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WG has multiple participants who have been involved in the development of cryptex, as well as implementation of RFC 6904.

The consensus in favor of the document appears solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

There have been no heated discussions or indication of extreme (or even mild) discontent. No threats of an appeal.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (25 October 2021) is 10 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866)


    Summary: 1 error (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).

--------------------------------------------------------------------------------


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not appear to require any formal reviews (e.g. no MIB or YANG modules, or media type/URI type definitions). 

(13) Have all references within this document been identified as either normative or informative?

References are separated into normative and informative categories.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No changes to the status of existing RFCs.  This document does not obsolete RFC 6904.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

I have reviewed the IANA Considerations, Section 9.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No IANA registries are created.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No formal languages.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG modules.