Subject: RE: Re: [AVT] WGLC: draft-ietf.avt-ulp-19.txt

From: "Botzko, Stephen" <[email-masked]>
Date: Tue, 28 Nov 2006 10:02:29 -0500

(BTW, I would assume that this last line should actually read, "after
encryption".)
Correct.  Sorry about the typo.

Steve worries that case 3 is better than case 4. I would argue that it
doesn't matter much. As before, we should assume that it is possible to
guess some of the packets being sent (i.e., known plaintext attacks must
be assumed). In particular, if I know some packet of an RTP stream, it
may be possible to guess subsequent ones.
So, while case 4 means that the attacker knows something of the
structure of the stream being sent, this sort of knowledge has to be
assumed anyway. So I would regard case 3 as an illusionary complication,
and cases 3 and 4 as being equally good.
I would still like to see a security analysis before we allow case 4.  I
am not at all convinced that 3 and 4 are equally secure.  Seems to me
that known relationships in the unencrypted data provide an avenue of
attack.  There are already some known patterns in the data (picture
start codes for instance).  But still, introducing lots more correlation
has to increase the vulnerability.  What am I missing here?

Steve B.

-----Original Message-----
From: Marshall Eubanks [mailto:[email-masked]] 
Sent: Tuesday, November 28, 2006 9:32 AM
To: Colin Perkins
Cc: Even, Roni; Adam Li; Botzko, Stephen; AVT WG
Subject: Re: Re: [AVT] WGLC: draft-ietf.avt-ulp-19.txt

Hello;

On 11/28/06, Colin Perkins <[email-masked]> wrote:
> Roni, Steve, Adam,
>
> On 28 Nov 2006, at 10:37, Even, Roni wrote:
> > I gave the draft for review to Steve Botzko from Polycom, he is 
> > involved with forward error correction work. The comments are from 
> > the point of view of using this work for conversional video 
> > conferencing.
> > Here are his comments
>
> Thanks for sending these comments. It's clear that a further revision 
> of the draft is needed before it can progress to the IESG.
>
<snip>
>
> > One minor comment on the encryption section - XORing pre-encryption 
> > creates a known mathematical relationship between the unencrypted 
> > data and the unencrypted XOR packets.  As mentioned in the text, it 
> > is certainly a bad idea to encrypt them with the same key.  I'm 
> > thinking that should be forbidden.  Its not clear that even 
> > encrypting XOR with a different key is secure enough.  Certainly 
> > best to XOR before encryption.

(BTW, I would assume that this last line should actually read, "after
encryption".)

XORing after encryption is merely protecting encrypted packets, and thus
raises no instrinsic issues.

XORing before encryption is the issue hereXOR, and there are 4
possibilities, as discussed in the draft (I have added numbers for
disucssion).

1       o The FEC stream may be encrypted, while the media stream is
not.
The draft implies that this SHOULD NOT be done.

2       o The media stream may be encrypted, while the FEC stream is
not.
The draft implies that this SHOULD NOT be done.

3      o The media stream and FEC stream are both encrypted, but using
        different keys.
The draft implies that this or case 4 SHOULD be done.

4      o The media stream and FEC stream are both encrypted, but using
        the same key.
The draft implies that this or case 3 SHOULD be done.

As far as I can tell, cases 3 and 4 are not distinguished further.

I would urge changing case 2 to MUST NOT. If the main stream is sent in
the clear and the FEC is protected (case 1) then you are wasting CPU
cycles, but doing no real harm, so SHOULD NOT is ok there.

If you do the reverse, case 2, then you are opening yourself to
known-plaintext attacks. In many case, much or all of some packets of an
RTP stream may be predictable or guessable (headers of MPEG frames,
configuration information, etc.). Suppose that you are XORing two
packets a and b and sending f(a), f(b) and a * b (where f() is a
cryptographic function and * means XOR). If I can predict or guess a,
then I can determine b. There may be enough structure in the packets to
make this possible even if I know nothing of f(), but if I can calculate
f(a), which may well be possible, then I can just look for
f(a) being sent and then determine b from the unencrypted FEC. If I only
know part of a, I may still be able to brute force this. Even if I am
XORing multiple packets together, I am still leaking information about
each packet into the XOR and sending it into the clear. This is bad,
bad, bad.

(The same sort of attacks would be possible in case 2 for any FEC
function, such as Reed-Solomon, as long as the attacker knows or can
guess what it is.)

So, I think case 2 needs to be MUST NOT. By the same reasoning, case 3
MUST NOT use a weaker encryption for the FEC than for the main rtp
stream.

Steve worries that case 3 is better than case 4. I would argue that it
doesn't matter much. As before, we should assume that it is possible to
guess some of the packets being sent (i.e., known plaintext attacks must
be assumed). In particular, if I know some packet of an RTP stream, it
may be possible to guess subsequent ones.
So, while case 4 means that the attacker knows something of the
structure of the stream being sent, this sort of knowledge has to be
assumed anyway. So I would regard case 3 as an illusionary complication,
and cases 3 and 4 as being equally good.

Regards
Marshall

>
> I'd also like to either see a revision that makes this restriction, or

> some explanation why the current approach is sufficient.
>
> Colin
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
>

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Marshall Eubanks" <[email-masked]>
Date: Tue, 28 Nov 2006 11:46:18 -0500

Dear Steve;

> has to increase the vulnerability.  What am I missing here?

These attacks fall under differential cryptanalysis, and AES (and DES
before it) were designed to be secure against those attacks. A chosen
plaintext attack against
DES, for example, required 2^47 chosen texts to succeed, which is a
little large even for, e.g., Gigabit / sec video. There are many older
ciphers that would not fare so well, so this just boil down to a
restriction of what ciphers should be allowed.

I worry more about the mixing of old and new keys, as allowed by the draft :

   The changing of encryption keys is another crucial issue needs to be
   addressed. Consider the case where two packets a and b are sent
   along with the FEC packet that protects them. The keys used to
   encrypt a and b are different, so which key should be used to decode
   the FEC packet? In general, old keys need to be cached, so that when
   the keys change for the media stream, the old key can be used until
   it is determined that the key has changed for the ULP FEC packets as
   well.

Suppose that the key is changed because the old key is compromised for
some reason. Then, (using my previous example) I am sending f(a),
f'(b) (where the ' denotes the new key) and _some_ encryption of a*b.

It seems to me that  in this case, I want to send f'(a * b). If I send
f(a *b), then the attacker, who presumably knows the key, can find a
and a*b, and thus b.

So, I would add

At the time of a key change, the new key SHOULD be used to encrypt any
packets involving an FEC combination of packets encrypted by the old
and new keys.

Regards
Marshall