W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2014

[Bug 25607] Need to advise authors about security considerations

From: <bugzilla@jessica.w3.org>
Date: Thu, 08 May 2014 21:33:28 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25607-7213-WcNalN7nPy@http.www.w3.org/Bugs/Public/>

--- Comment #4 from Ryan Sleevi <sleevi@google.com> ---
Bug 25431 is about an entirely different attack than simply "warning" - it's
about the implementation making it impossible to use RSA-ES securely (which it
can be, with careful consideration - as in the case of a "good" TLS impl)

Bug 18925 is a re-statement of the need not to introduce issues like Bug 25431,
which was introduced, unfortunately, with the addition of error codes and the
abstracted idea of wrap/unwrap.

Bug 25569 is about adding new algorithms entirely, particularly ensuring that
they are part of the "Recommended for implementors" section. Your proposal does
not change this need.

Bug 23499 is a dupe of this (or more aptly, this is a dupe of it), for which
was addressed on the list. This is different wording, but conceptually the

Further, the guidance proposed here isn't really sufficient. I disagree with
your analysis of CTR, CBC, and CFB. While yes, it's true that in and of
themselves they have risks, they are not 'doomed' (RSAES is far more likely to
be considered doomed - as would be MD5 and RC4). That is, you can add
authentication and construct safe uses - as draft-mcgrew shows.

It's important for you to realize that listing all of the failures in the
algorithms is, implicitly, recommending a set of 'safe' algorithms (eg: those
without risks). That is, the omission of attacks for ECDH (of which there exist
timing attacks) or ECDSA (which, of course, is absolutely and completely fatal
if the nonce isn't random, and hence why many uses are now taking to
incorporating H(M) in the nonce when computing signatures for M) implies
they're inherently safe, but they're not.

If the spec were to instead say "These are the algorithms new [web developers]
are recommended to use when implementing new protocols", it's quite obvious to
see there's a fundamental problem - you shouldn't be implementing new protocols
WITHOUT understanding all of these caveats.

I have serious doubts that listing the attacks will save anyone, ever, from
making a cryptographic mistake. They fall into simple use cases:

1) Implementing an existing protocol
  - Regardless of whatever normative advice in this spec, they're going to
follow that protocol's spec. Maybe they'll read the BIS and Errata, maybe they
won't. Here, all that matters is what the market does, not whatever a spec says
2) Implementing a new (standard) protocol
  - Either the protocol set out good advice or it didn't. JOSE is an example
of, arguably, good advice (notwithstanding Microsoft's request to add RS1 as
valid for JWS in Bug 25570)
3) Implementing a new (custom) protocol
  - Look, here, you're doomed if you don't understand all these attacks
already. Even if you say "use AES-GCM", you're still going to have issues with
key selection, derivation, etc.

Any advice against is, implicitly, advice for. And "advice for" is something
this WG has explicitly decided against.

You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 8 May 2014 21:33:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:22 UTC