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

[Magnus Westerlund <[e-mail]>]

Hi Cullen and WG,

Implementors, please see question at the end!

On 2019-05-17 20:34, Cullen Jennings wrote:


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.




So my read of 5.1 is that does this. Clearly we need to make the text clear that it does that - what part of the 5.1 makes you think the padding is stripped from the  payload ?

Perhaps to make it explicitly clear we should change

"* Payload: The RTP payload of the original packet”

to be

"* Payload (including padding) The RTP payload (including passing) of the original packet”

Yes, making it explicit is necessary. The payload and the padding are two distinct protocol parts, thus I think using "Including" is not the right way of formulating it.

I think it would be clearer to do this:

OLD:

   3.  Form a synthetic RTP packet with the following contents:

       *  Header: The RTP header of the original packet with the
          following modifications:

       *  The X bit is set to zero

       *  The header is truncated to remove any extensions (i.e., keep
          only the first 12 + 4 * CC bytes of the header)

       *  Payload: The RTP payload of the original packet

NEW:
   3.  Form a synthetic RTP packet with the following contents:

       *  Header: The RTP header of the original packet with the
          following modifications:

       *  The X bit is set to zero

       *  The header is truncated to remove any extensions (i.e., keep
          only the first 12 + 4 * CC bytes of the header)

       *  Payload: The RTP payload of the original packet

       *  Padding: If padding is applied (P=1), include the padding count octet and any padding octets.


I would also note that likely the padding need to be explicitly discussed
as being applied in the inner stage so that the outer packet generation
don't attempt to strip it away if P=1. Otherwise an MD could screw up the
packet completely.

Actually a question here to the people that has
implementation. If P=1 in the RTP header and they apply only the outer part
of DOUBLE decryption will their stacks actually attempt to strip an RTP padding off using the
OHB config octet as padding byte count?


Cheers



Magnus Westerlund


----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]<mailto:[e-mail]>
----------------------------------------------------------------------