Subject: Re: [saag] POODLE avant le chein

From: Peter Gutmann <[email-masked]>
Date: Thu, 16 Oct 2014 08:24:15 +0000

"Black, David" <[email-masked]> writes:

>One down (Firefox) ...
>
>https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/

On another list there's a discussion that www.poodletest.com is reporting
Firefox (latest versions) vulnerable or not vulnerable for different people,
there's no obvious pattern (although the sample size is currently rather
small).

>Nit: Le mot en francais est "le chien", pas "le chein" ;-).

I was also wondering about the phrasing, I would have expected "POODLE:
Attention au chien", what's the significance of saying "before the dog"?
Also, if someone can give the next attack that comes along a feline name they
have my permission to use this:

https://www.flickr.com/photos/nzphoto/15241814340/lightbox/

CBC-HMAC Authenticator Truncation seems like one viable name.

Peter :-).

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 16 Oct 2014 08:34:05 +0000

Jim Schaad <[email-masked]> writes:

>CMS has defined an AEAD structure to be used with authenticated algorithms.
>The only algorithms currently defined are AES-CCM, AES-GCM and RFC 6476. The
>first two don't use CBC so are not affected.  The last one does encrypt then
>MAC so that the entire encryption stream is MAC-ed.  My understanding is that
>this means that it should not be an issue as the pad is covered by the MAC
>value.

That was by deliberate design, MAC everything including metadata [0].  It's
the same for RFC 7366, "Encrypt-then-MAC for Transport Layer Security (TLS)
and Datagram Transport Layer Security (DTLS)", that finally fixes a problem
that's been plaguing SSL and TLS for 10-15 years (and what a battle it was
getting it adopted by the TLS WG).

Peter.

[0] Thanks to Jim for pointing out in an early draft that I'd missed a bit :-).

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 16 Oct 2014 14:39:20 +0000

Watson Ladd <[email-masked]> writes:

>So, what is the actual security S/MIME provides? It's probably violates
>several assumptions about the authenticity of messages, by not authenticating
>ciphertext, and has plaintext revealing padding oracles as a result.

You'd have to work pretty hard to create an implementation of a store-and-
forward protocol that could be used as a padding oracle.

Peter.