[Bug 25607] Need to advise authors about security considerations

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

--- Comment #1 from Ryan Sleevi <sleevi@google.com> ---
Hi Rich,

As discussed on the list, the WG has discussed proposals similar to yours - at
significant length - and has opted not to produce such recommendations.

The issue with your proposal should hopefully be clear - as the spec cannot be
updated, it creates a point in time snapshot of a security state, while
implying it's a forward thinking security state. That is, authors who revisit
this document in a year, three years, or however long until the next
cataclysmic cryptographic event, will continue to be advised that X is safe,
when it is not.

It also creates a deeply slippery slope - is the spec primarily for authors or
implementors? If implementors, shouldn't they also be aware of all the ways in
which implementations can be done poorly? For example, Manger's attack on OAEP,
or the (seemingly many) non-constant-time ECC curve implementations?

Why not indicate a + in SHA-1, as we already know it's showing weaknesses like
MD5? Is it because we think they aren't that bad yet? Why not for RSA-SSA?

You can quickly see that this is a rather arbitrary solution that doesn't
scale, and doesn't fully address constituencies of the spec. I can certainly
understand that this might make you feel good about one class of attacks, but
it doesn't really address things. 

As you have already received feedback from the W3C Contact (Harry), having the
IFRT/CFRG produce such a document is preferred.

(In reply to Rich Salz from comment #0)
> This defect is in collaboration with Kenny Paterson.
> I believe that taking the fixes below will also address 18925, 23499, 25431
> (maybe, by lack of use:), 25569

It does not fix these bugs.

> 
> Section 5.2
> =========
> In the second paragraph, after the first sentence add a forward reference to
> see section 18.1
> 
> 
> Section 18.1
> =========
> Add the following paragraph after the heading, before the table:  "The table
> below indicates which algorithms, and uses, are registered by this
> specification. A blank field means no registration, a check means
> registration, and a plus means registration, but that there are known
> security issues with that particular combination. (See Security References,
> below.)"
> 
> In the table, change the following entries to a plus sign
>  RSAES-PKCS1-v1.5: encrypt and decrypt columns
>  AES-CTR: all columns
>  AES-CBC: all columns
>  AES-CFB: all columns
> 
> 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
> SHOULD never be used to generate data."

Considering that the WG does not specify MD2 and MD5, it's odd that you would
include this at all.

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

Received on Thursday, 8 May 2014 15:46:55 UTC