Subject: [Cfrg] possibly dumb question about the opus codec and padding

From: Stephen Farrell <[email-masked]>
Date: Wed, 06 Jun 2012 15:54:44 +0100

Hiya,

I'm reviewing the opus codec spec [1] for this week's
IESG telechat.

On p20, they say to zero out padding bits to avoid a covert
channel.

Now I don't know how often that might happen, nor for how
many bits (its a complicated beast;-) but I wondered if
there's a possible problem there if the resulting encoded
bits are stream-enciphered with a not-quite-good-enough
cipher and for whatever reason there's a lot of padding.

I could ask 'em to say "pad randomly if these may be
stream enciphered since you can hide the covert channel
in the ciphertext nicely in any case" but it may be
hard to know from within the codec if a stream cipher
will be used elsewhere in the stack. Or, perhaps I
could suggest they add a warning that these zero'd
padding bits would be problematic if you use a crap
stream cipher, but then that's motherhood/apple-pie
and would be ignored, buried as it is within the bowels
of a 331 page spec.

Any thoughts? (Most usefully before 1530 UTC tomorrow:-)

Ta,
S.

[1] http://tools.ietf.org/html/draft-ietf-codec-opus-14

---

From: Jon Callas <[email-masked]>
Date: Wed, 6 Jun 2012 08:10:54 -0700

In my opinion, the best compromise on this would be to change MUST to SHOULD.

The spec as written says you MUST zero-pad, but you MUST accept any padding. That means that a non-compliant implementation is still interoperable, and the MUST pad is just a fig leaf. Be honest with yourself.

There is always a dilemma, because they're right, there's a covert channel. On the other hand, zero-padding creates known plaintext. Pick your poison.

In general, worrying about covert-channels is not worth it. If someone wants to create a covert channel, they can. There are infinite ways to create one, and worrying about it isn't worth the effort. Moreover, if you leave the easy way to create one in, you have an easy way to detect one, too. You can also argue that anyone who wants a covert channel wouldn't use that, because a covert channel has to be -- well, you know, *covert* -- and sticking data in the padding is pretty darned obvious.

Since I brought it up, the known plaintext in the zero-padding isn't a huge leak, either and I wouldn't worry about it. 

Thus, I think the most reasonable thing to do would be to just make the MUST a SHOULD because the MUST-accept pulls all the teeth out of the MUST-pad.

	Jon

---

From: Russ Housley <[email-masked]>
Date: Wed, 6 Jun 2012 11:57:31 -0400

I'd encourage the documentation of the concerns with known plaintext (the zero pad) and a poor stream cipher.  It seems like a simple sentence or two in the Security Considerations section.

Russ

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Wed, 6 Jun 2012 09:55:00 -0700

On the other hand, if a stream cipher is so weak that it can be broken
with a bit of known plaintext, I'm pretty confident that we shouldn't
use that stream cipher in any case.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Russ Housley
Sent: Wednesday, June 06, 2012 11:58 AM
To: Stephen Farrell
Cc: [email-masked]
Subject: Re: [Cfrg] possibly dumb question about the opus codec and
padding

I'd encourage the documentation of the concerns with known plaintext
(the zero pad) and a poor stream cipher.  It seems like a simple
sentence or two in the Security Considerations section.

Russ

> [1] http://tools.ietf.org/html/draft-ietf-codec-opus-14

_______________________________________________
Cfrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/cfrg

---

From: Hal Finney <[email-masked]>
Date: Wed, 6 Jun 2012 16:52:00 -0700

What time is it when you're worrying about known plaintext in your cipher?

Time to get a new cipher.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 07 Jun 2012 01:15:14 +0100

> Time to get a new cipher.

Sure. But that's not what happens with popular ciphers is it?
They tend to hang around past their sell-by date in at least
some cases. Current news wrt md5 for example.

And the problem mightn't be the algorithm but bad keying. Old
news wrt WEP for example.

Part of the reason for asking is a concern that it might be
possible to manipulate things so lots of padding bits are
added. (I don't know that yet, trying to find out.) If that's
not the case then there's probably nothing to worry about in
this case.

But more generally, do we have any results about how much
known plaintext might be (un)safe with a not-quite-good-enough
cipher that could help when considering protocol design?

S

---

From: Jon Callas <[email-masked]>
Date: Wed, 6 Jun 2012 18:25:34 -0700

I might need to clarify my remarks a bit.

I don't think a few bits of known plaintext is a serious issue. I mean heck, pick just about any XML document and it's got an entire *block* of known plaintext in it via its XML/DTD header.

On the other hand, there are a number of problems including the Mister/Zuccherato attack on OpenPGP and the Paterson et al. attack on SSH that boiled down to known plaintext. Add to that the PKCS1 attacks, and any number of padding oracles, it can't just be waved away.

Back to the first hand, zeroing out a field isn't a serious issue, and I don't mean to imply that it is.

But moving on to the third hand, worrying about a few bytes of covert channel is equally as daft.

My larger point was that saying you MUST zero a field to stop a covert channel is no more (nor less) sensical than saying you MUST NOT zero it to stop known plaintext. It's sort of, "I'll see your paranoia and raise you one." Especially when that MUST for zeroing is followed up with a MUST accept non-zero. 

That's why I opined that changing the MUST to a SHOULD is a good idea. I truly believe that one SHOULD zero all unused bits because of cleanliness. It's just a good idea. 

If you don't like changing that MUST to a SHOULD on zeroing, then at least change the MUST accept to MUST reject. If you're going to legislate, have a backbone about your legislation.

	Jon

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 07 Jun 2012 02:51:37 +0100

Thanks Jon, I asked if they'd change MUST->SHOULD. (Not,
its not my spec, its the codec wg's.)

S

---

From: David McGrew <[email-masked]>
Date: Fri, 8 Jun 2012 10:24:04 -0400

>> Time to get a new cipher.

+1 on that.

> news wrt WEP for example.

Agreed.   There are many good ciphers that appear to be secure even when the attacker can adaptively choose exabytes worth of data.  This list includes AES and many other 128-bit wide block ciphers used in standards.   However, it doesn't include RC4 and 3DES, the latter because of its 64-bit block width.  

> cipher that could help when considering protocol design?

There is an interesting threshold around one gigabyte, which corresponds to the birthday bound for 64-bit block ciphers.  

Another interesting and related question is: how much known plaintext is available in network encryption protocols?  Many protocols that get encrypted are predictable enough that an attacker who has done their homework should be able to guess some fraction of the plaintext.  

David

---

From: David McGrew <[email-masked]>
Date: Fri, 8 Jun 2012 10:41:40 -0400

Hi Jon,

On Jun 6, 2012, at 9:25 PM, Jon Callas wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

This is a good point: known plaintext can make chosen-ciphertext attacks easier, even if the underlying block cipher resists exabytes of known plaintext.  I think the main lesson from this is: use authenticated encryption.   But I think it is reasonable to say that avoiding known plaintext is a good idea if it is not possible to ensure that encryption uses AE.

David

> -----BEGIN PGP SIGNATURE-----
> Version: PGP Universal 3.2.0 (Build 1672)
> Charset: us-ascii
> 
> wj8DBQFP0AMRsTedWZOD3gYRArMAAKDOj78r2s+05WDeO6cWDvdPAeYz1QCeNbOO
> oZm9XwLUmxpOFzPI0+SDSq4=
> =fqjl
> -----END PGP SIGNATURE-----