[Bug 25607] Need to advise authors about security considerations

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607

--- Comment #17 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Rich Salz from comment #16)
> I am updating my request for changes, based on the draft I see today. All
> other issues are closed, and this is what remains.  It is, still, the core
> concern of this bug report.
> 
> 
> In Section 6.2, after the the first sentence of the first paragraph add
> "(See also section 21, below.)"
> 
> In section 21, after the first sentence, add the following: "A blank field
> means no registration, a check means registration, and a plus means
> registration, but that at the time of this writing there are known security
> issues with that particular combination. (See Section 23.2, Security
> References, below.)"
> 
> In section 21, in the table, for the rows labeled AES-CTR, AES-CBC, AES-CFB,
> and SHA-1 replace the check-mark with a plus sign (or other graphic).

You will need to actually expand upon the logic you chose here.

For example, ECDH should include a check mark with a plus sign, seemingly by
your logic, since WebCrypto is vulnerable to the Static Diffie-Hellman Problem.

Likewise, ECDSA should include a check mark with a plus sign, since ECDSA is
known-vulnerable to nonce-reuse.

In fact, I would be hard pressed to find a single example, out of all of the
algorithms, where a plus sign would not be appropriate - save for, perhaps,
SHA-2. (HKDF is seemingly "vulnerable", by your logic, for the same reason you
preclude MD5 even though HMAC-MD5 doesn't suffer the same issues)


> 
> In section 21, after the table, add the following text: "Entries with a plus
> sign SHOULD only be used when interoperating with existing formats and
> protocols.  Although not registered in this document, the digest mechanisms
> MD2 and MD5 referenced in various related standards SHOULD never be used to
> generate data."  Replace the words "plus sign" with whatever description is
> appropriate for the graphic you choose.

I strongly object/oppose this. You are the only person in this WG advocating
MD2/MD5. You're proposed inclusion is seemingly an attempt to circumvent any WG
discussion of these, by trying to include a normative note that precludes their
use.

At best, only your first sentence should be included, and only if the above
criticisms are somehow dealt with.

> 
> Include a Security References section, suggested as 23.2. Include the
> documents listed in the original description of this bug report. Considering
> adding a reference to Graham's "cryptosense" blog posting, in whatever form
> you find appropriate.

I still, individually, strongly oppose this. I have no idea what you view the
intended audience of this spec is. For the users that most people are concerned
about writing "bad code", it is no question that they will write bad code no
matter what. For those that will actually read the spec, but still write bad
code, the documents listed will do nothing to provide clear and concise
understanding of the issues.

I'm sensitive to there being algorithm considerations, but an API document
remains the wrong place to put them, the same way that discussing the best way
to do ambient occlusion has no place in the WebGL spec, nor do discussions
about sound waves belong in the Web Audio API. That is, these are intrinsic
pieces of information that any knowledgeable practitioner must understand.

This may seem extreme. I am aware how sensitive and sacrosanct you view crypto.
But this is no different a "attack" than mixed content, unsafe eval, innerHTML,
sourcing third-party scripts (i.e.: by hosting them on CDNs such as Akamai,
which may serve hostile scripts instead), or any of the other ways that web
operators can knowingly introduce security vulnerabilities.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Monday, 30 June 2014 19:26:57 UTC