[Perc] Magnus Westerlund's Discuss on draft-ietf-perc-double-10: (with DISCUSS and COMMENT)

[Magnus Westerlund via Datatracker <[e-mail]>]

Magnus Westerlund has entered the following ballot position for
draft-ietf-perc-double-10: Discuss

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


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------



1. Section 5.1:

To me it appears that one fundamental security flaw exists in the definition of
the inner encryption. That is the fact that RTP padding is not included into
the inner encrypted part. This prevents the application of RTP padding to
prevent the potential privacy leakage that "Guidelines for the Use of Variable
Bit Rate Audio with Secure RTP" (RFC 6562) documents. To prevent this type of
information leakage and other privacy preserving operations based on applying
RTP padding it would be necessary to include the RTP padding into the inner
encrypted envelope. Appendix A figure indicates that is the case, but the
process description in 5.1 is not matching that.

2. Section 5.1:

   1.  Form an RTP packet.  If there are any header extensions, they
       MUST use [RFC8285].

I got the impression from the framework that it was possible to have some
header extension being encrypted using the inner key as (Section 4:3) says:

   If there is a need to encrypt one or more RTP header extensions end-
   to-end, the endpoint derives an encryption key from the E2E SRTP
   master key to encrypt header extensions as per [RFC6904].

 That is missing from this step as it can't be applied in step 4. And shouldn't
 the headers protected in this fashion with the inner keys be part of the
 authenticated synthetic packet?

3. Section 5.2:

This is minor but still a significant inconsistency:

   3.  A Media Distributor can add information to the OHB, but MUST NOT
       change existing information in the OHB.  If RTP value is changed
       and not already in the OHB, then add it with its original value
       to the OHB.

4.  If the Media Distributor resets a parameter to its original
       value, it MAY drop it from the OHB.  Note that this might result
       in a decrease in the size of the OHB.

So reseting back to original value, is according to 3 not allowed. I think the
MUST NOT is wrongly formulated. I assume that the point is that any field value
carrying an original value MUST NOT be changed, however, if the field is
changed back to its original value, the value SHALL/SHOULD be removed from the
OHB?

4. Section 5.2:

 ... SHOULD use an independent salt for each recipient,

Is that possible on any other legs than MD to MD? What has been statated is
that all end-point are required to use the same sal for a session as that is
not included in the EKT. Putting a SHOULD requirement on something that is not
possbile appears counter productive.

5. Section 7.1:

This section fails to make it clear why RTX packets are retransmitting the
double encrypted packets. In normal application of SRTP the buffered packet and
what is used for constructing the RTX packet is the unencrypted one. Thus the
equivalent for an MD would be to handle the Inner protected only in its cache.
Is the reason that an endpoint that recovers a packet anyway have to pass it
through the double decryption process and thus it is to avoid a exception case
for the endpoint? If that is the case, please note it in the text.

6. Section 7.2:

I fail to see how one can follow this procedure and generate anything that is
workable. The reasons is that that the primary encoding and each of multiple
redundancy encoding all share the same SSRC and have no independent sequence
number space or timestamp space. Thus, I don't see how it is possible to create
inner encrypted payloads for each of the primary and redundnacy encoding
without two time pads. Why wasn't the simple choice applied here. That is to
treat RED as a single endpoint to endpoint format. Thus making it robust if
packets are lost on the path, but the MD's can't recreate a packet based on a
redundancy paylaod and inject that instead.

I don't see how that this is a correct statement. As RED does not have
different SSRCs for the different media encodings what it does can't be
represented in FlexFEC.

 "Note that Flex FEC [I-D.ietf-payload-flexible-fec-scheme] is a
   superset of the capabilities of RED.  For most applications, FlexFEC
   is a better choice than RED."

7. Section 9:
        When this is done, the cryptographic
   contexts used for decryption and re-encryption MUST use different,
   independent master keys and master salts.

        Related to discuss item 4 and here at different RFC 2119 levels.


8. Section 9. The use of AES-GCM as symmetric algorithms results in that the
source authication level for the inner part has a limited scope, in that any
endpoint can create a double protected packet, not only the one that which SSRC
it is as there are no cryptographic protection on that level. I think that
point is significant for something that is primarily targeting group
communication scenarios.


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

A. Section 3.1:
   Here "PRF_n(k, x)" represents the AES_CM PRF KDF [RFC3711] for
   DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM algorithm and AES_256_CM_PRF
   KDF [RFC6188] for DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM algorithm.

I would recommend that you are a bit more specific about your references. So
for the AES_CM PRF I think that should actually point to section 4.3.3 or at
least 4.3 of RFC 3711.

B. Section 1 and 4:

Section 1 says:
    In that
   case, the original value of any RTP header field that is changed is
   included in a new RTP header extension called the Original Header
   Block.

Section 4 says:
In the encryption process, the OHB is
   appended to the RTP payload.

I assume it is 1 that should be changed and this is a missed case of moving the
OHB from header extensions to encryption payload.

C. Section 4:

In the encryption process, the OHB is
   appended to the RTP payload.

I think that is a bit imprecise.

Considering the diagram in Appendix A.

       0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<++
    |V=2|P|X|  CC   |M|     PT      |       sequence number         | IO
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO
    |                           timestamp                           | IO
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO
    |           synchronization source (SSRC) identifier            | IO
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ IO
    |            contributing source (CSRC) identifiers             | IO
    |                               ....                            | IO
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O
    |                    RTP extension (OPTIONAL) ...               | |O
+>+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O
O I |                          payload  ...                         | IO
O I |                               +-------------------------------+ IO
O I |                               | RTP padding   | RTP pad count | IO
O +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O
O | |                    E2E authentication tag                     | |O
O | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O
O | |                            OHB ...                            | |O
+>| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |+
| | |                    HBH authentication tag                     | ||
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ||
| |                                                                   ||
| +- E2E Encrypted Portion               E2E Authenticated Portion ---+|
|                                                                      |
+--- HBH Encrypted Portion               HBH Authenticated Portion ----+

If we follow the figure, but I am uncertain as seen by Discuss 1. The OHB is
added after the inner protected part (RTP paylaod, RTP padding and E2E
authentication tag).

D. Section 5.1:

   5.  Replace the header of the protected RTP packet with the header of
       the original packet, and append an empty OHB (0x00) to the
       encrypted payload (with the authentication tag) obtained from the
       step 4.

I assume that this should say
   5.  Replace the header of the protected synthetic RTP packet with the header
   of
       the original packet (to restore any header extensions), and append an
       empty OHB (0x00) to the end of the encrypted payload (with the
       authentication tag) obtained from the step 4.

E. Section 5.2:

   In order to modify a packet, the Media Distributor decrypts the
   received packet, modifies the packet, updates the OHB with any
   modifications not already present in the OHB, and re-encrypts the
   packet using the the outer (hop-by-hop) cryptographic key before
   transmitting.

I think this text should be clear that the applied key for the encryption is
not the same as the one used for the decryption as it is depending on who is
the next hop receiver, if that is MD or another endpoint. The text after the
bullet list could be more specific to point.

This comment applies to bullet 1 and 5 that should be clarified on that.

F. Section 5.2: Bullet 2:
Should mentions that some header extensions may be changed.

G. Section 8:

If no other header extensions are present in the
   packet and the OHB is introduced, that will consume an additional 8
   octets.  If other extensions are already present, the OHB will
consume up to 4 additional octets.  Packets in repair mode will carry
   additional repair data, further increasing their size.

More leftovers from change from header extension to payload for OHB.