[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] RTP: Confidentiality mechanisms

Hi David,

David A. Mcgrew wrote:

Mats,

thanks for bringing this issue up, more inline:

Mats wrote:


Summing up, I would like to see something like (others, please
comment):

  Secure CBC mode requires that the first block of each packet
  be XORed with random, independent, IVs of the same size as the
  cipher's block size. For RTCP, this is (partially) achieved by
  prepending each packet by a 32-bit random string, independently
  chosen for each packet. For RTP, the fact that the timestamp and
  sequence number start from random values are used to this end, and
  no prepend is done. It should however be noted that the randomness
  in both cases (RTP, RTCP) is limited, and for RTP, consecutive
  packets will not be independently randomized. High-security
  applications SHOULD consider other, more conventional, protection
  means.


Clearly these mechanisms should be deprecated.  It might be best to have text
that states that fact up front, and then provides the details for the interested
reader.  It's hard to judge text without knowing where it would go in the
document, but your text looks fine.

Looking through Section 9.1 of RFC1889 makes me wonder if perhaps the entire
confidentiality mechanism described there should be deprecated.  It's DES in CBC
mode with a 32-bit IV.  Because it lacks a full IV, there are attacks which will
work against it with less than 2^56 effort.  It is certainly good security
practice to deprecate weak legacy crypto whenever possible, though perhaps it
would be best to wait until there's an accepted alternative for RTP.

I am inclined to agree. It is really a non-standard crypto transform
that is described. In fact, one alternative way to conceptually think
of the encryption is as follows:

1. The packet header (or part thereof) is prepended with randomness
   and encrypted in ECB (electronic code book mode).
2. The result of step 1 is used as IV for the CBC encryption of
   the remainder, using the *same* key as in step 1.

It seems to me that defining this new "mode of encryption" is
against the AVT WG's earlier stated policy not to define actual
crypto transforms. I too would therefore ask the WG to consider
removing this altogether, rather than adding the text I proposed.

Best,

/Mats

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt