Re: "Recommended" is a bad word :)

On Mon, May 12, 2014 at 6:56 AM, Salz, Rich <rsalz@akamai.com> wrote:

> > Do you view these comments as "formal objection"?
>
> When do you need an answer?
>
> On the one hand, I don't want to be an ass.  On the other hand, you asked
> for IETF review and you got it, in the form of email from Kenny and
> colleagues.
>
> There is no risk in incorporating the security concerns into the document;
> a weak mechanism is not going to suddenly "get better" it's only going to
> get weaker.


As has been addressed on the bug, the criteria for "weak" is clearly
misleading and misrepresentative. Proposals that flow from this are
misguided.

RSA-ES is "weak" if you leak encryption/decryption success failure.
RSA-OAEP is "weak" if you leak the state of the first octet (Manger's
attack)
AES-GCM is "weak" if you leak the computed table state.
AES-GCM is "weak" if you consider AES-CTR (which it builds upon) weak.

I don't believe you view AES-GCM as week, given your comments in the IETF
TLS WG, so it's clear that we have _some_ bar for defining what constitutes
weak.

You have listed AES-CTR as "weak", but it's clear from AES-GCM that it can
be used securely.
You have listed AES-CBC as "weak", but it's clear from
http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2 that it can
be constructed in a secure manner.

Your definition of "weak" is thus without clear guidance, and thus not
something the WG can maintain, particularly in light of exploring how
additional algorithms are to be added.

The strength or weakness of a given algorithm IS context-dependent. Within
TLS, it is believed that the use of RSA-ES for the PreMasterSecret is
"secure", although admittedly full of sharp edges that can be used to make
it insecure. Within TLS, the use of Mac-then-Encrypt means that CBC is
insecure - although proposals such as Encrypt-then-Mac show how to make it
secure.

A document such as
http://tools.ietf.org/html/draft-irtf-cfrg-cipher-catalogis a far
better tool for exploring these nuances, as well as exploring the
various cryptoanalytic attacks and potential mitigations.

Note that the Security Considerations are already being reworked in light
of the TAG guidance to provide clearer context for the non-normative aspect
of every algorithm - that is, there are NO algorithms within this
specification that are "Mandatory to Implement". This spec COULD be
comprised of 19 specifications (18 algorithms + this specification) and the
normative requirements would not change.


> Given that, I do not understand such strongly-expressed concern about
> putting such advice into the current document.  I am also puzzled that
> nobody else on the WG has expressed any real opinion (we security types are
> a paranoid bunch:). As such, I am leaning toward making this a formal
> objection, but I will need to discuss with colleagues first.  So, when do
> you need to know?
>
> Thanks.
>
>         /r$
>
> --
> Principal Security Engineer
> Akamai Technologies, Cambridge, MA
> IM: rsalz@jabber.me; Twitter: RichSalz
>
>
>