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.

Then tweak the wording to be
   but that, at the time of publication of this document, there are known security issues with that particular combination. (See Security References, below.)"

Also, attacks get better and weak crypto does not get stronger. So while the warnings may become incomplete over time, the ones given here will never become wrong.

I disagree with your assessment about fixing the other bugs.

I only mentioned MD2 and MD5 in case someone followed the RFC for PKCS1 and wanted to have complete support for it. If you want to drop that sentence, fine.

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 same.


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.

At least arguing in BZ you get more than 140 chars.  Sigh.

I don't care what your opinion is about particular ciphers, any more than you should care about mine.  A band of cryptographers and the open literature should be taken as definitive.  Not what you are I say.

I believe that if you take the changes here, you can close those other BZ reports with a straight face saying "we didn't disallow anything but we put in real security considerations."  I will contact the other reporters for their opinion.

(In reply to Rich Salz from comment #5)
> At least arguing in BZ you get more than 140 chars.  Sigh.
> 
> I don't care what your opinion is about particular ciphers, any more than
> you should care about mine.  A band of cryptographers and the open
> literature should be taken as definitive.  Not what you are I say.

And you're needlessly reducing the security analysis, which is often triggered on specific conditions or combinations.

Implying that they're unsafe-for-any-purpose is not a fair or accurate representation, and covering the nuances is a far more involved task that is suitable for the CFRG or similar, as has already been discussed.

This is the entire point - ANY discussion of "security" inevitably depends on the context, and it's this context that we clearly have disagreement on, and for which opinions clearly matter.

> 
> I believe that if you take the changes here, you can close those other BZ
> reports with a straight face saying "we didn't disallow anything but we put
> in real security considerations."  I will contact the other reporters for
> their opinion.

If there is a warning about currently known weaknesses and a note that this is a point-in-time snapshot and there is a need to keep abreast of the latest advances, there's a decent chance users of the API will at least pay some attention to algorithm choice.

If there is no mention of these issues, there is an excellent chance that users of the API will not pay attention to this and end up using weak algorithms. 

In the first case, the application may still be insecure for any number of reasons. In the second case the application will almost certainly be insecure.

Given this choice, I favour the first case. 

If the CFRG could maintain a "security status of commonly used crypto algorithms" document that would be extremely useful - and not just for this API - but whether they do or not the first option seems preferable.

Kenny is now co-chair of the IETF CFRG.

As part of the ongoing INRIA review of the spec I wrote up the current situation re: the security of the methods in the public working draft. Feedback welcome pending the final version which will be a chapter in the review.

http://cryptosense.com/choice-of-algorithms-in-the-w3c-crypto-api/

https://dvcs.w3.org/hg/webcrypto-api/rev/7a79e816e31b

I read the commit diff and nothing in it addresses any of the issues raised here:
     The misleading term "recommended" is still used.
     There is no section on security references
     Specific guidance about avoiding known-bad mechanisms is not present

If you insist on putting it into RESOLVED state, the honest thing to do is make it WONTFIX.

(In reply to Rich Salz from comment #11)
> I read the commit diff and nothing in it addresses any of the issues raised
> here:
>      The misleading term "recommended" is still used.
>      There is no section on security references
>      Specific guidance about avoiding known-bad mechanisms is not present

Please review the editor's draft https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html (in particular, the change from https://dvcs.w3.org/hg/webcrypto-api/file/71498804a64d/spec/Overview.html )

The language that was incorporated was language from Vijay that you had (seemingly) agreed met your requirements.

To your specific points:
- The misleading term "recommended" is still used.
  - Please review the editor's draft. In particular, see https://dvcs.w3.org/hg/webcrypto-api/raw-file/71498804a64d/spec/Overview.html#algorithm-recommendations

  The term "recommended" has a particular meaning in the specification world, not just the security world, and given as this is a specification, it's used to signify just that - recommended for implementers of this spec.

- There is no section on security references
  - I believe we're at a WONTFIX here, because we've identified that the spec is not a place to discuss these

- Specific guidance about avoiding known-bad mechanisms is not present
  - Please review the editor's draft. In particular, https://dvcs.w3.org/hg/webcrypto-api/raw-file/71498804a64d/spec/Overview.html#algorithm-recommendations

>
> If you insist on putting it into RESOLVED state, the honest thing to do is
> make it WONTFIX.

There has certainly been every effort to understand and respect your concerns. Additionally, multiple explanations have been provided as to why some of these concerns are out of scope or inappropriate for this spec.

I encourage you to read the editor's draft, as a whole, at https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html - as well as review the log - https://dvcs.w3.org/hg/webcrypto-api/log

This bug contains many elements that are duplicate with already existing bugs (as you note), and so other elements of concern have been addressed separately, in those bugs.

(In reply to Ryan Sleevi from comment #12)
> (In reply to Rich Salz from comment #11)
> > I read the commit diff and nothing in it addresses any of the issues raised
> > here:
> >      The misleading term "recommended" is still used.
> >      There is no section on security references
> >      Specific guidance about avoiding known-bad mechanisms is not present
> 
> Please review the editor's draft
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html (in
> particular, the change from
> https://dvcs.w3.org/hg/webcrypto-api/file/71498804a64d/spec/Overview.html )
> 
> The language that was incorporated was language from Vijay that you had
> (seemingly) agreed met your requirements.
> 
> To your specific points:
> - The misleading term "recommended" is still used.
>   - Please review the editor's draft. In particular, see
> 
>   The term "recommended" has a particular meaning in the specification
> world, not just the security world, and given as this is a specification,
> it's used to signify just that - recommended for implementers of this spec.

The term "recommended" has caused continual confusion by the public in the two sense of recommendeed for implementation vs. recommended for new protocols. I believe one suggestion was to use "Suggested for interoperable implementation".
Rich and Ryan, would that help?

So we could replace "18.2. Recommended algorithms" -> "18.2. Suggested algorithms for interoperability"

"Thus users of this API should check to see what algorithms are currently recommended and supported by implementations" ->
"Thus users of this API should check to see what algorithms are currently supported by implementation. At the state of this publication, interoperability is given by the test-suite available at @@."

That may also help the bugs about interoperability being raised elsewhere.

> 
> - There is no section on security references
>   - I believe we're at a WONTFIX here, because we've identified that the
> spec is not a place to discuss these
> 
> - Specific guidance about avoiding known-bad mechanisms is not present
>   - Please review the editor's draft. In particular,
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/71498804a64d/spec/Overview.
> html#algorithm-recommendations
> 
> >
> > If you insist on putting it into RESOLVED state, the honest thing to do is
> > make it WONTFIX.
> 
> There has certainly been every effort to understand and respect your
> concerns. Additionally, multiple explanations have been provided as to why
> some of these concerns are out of scope or inappropriate for this spec.
> 
> I encourage you to read the editor's draft, as a whole, at
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html - as
> well as review the log - https://dvcs.w3.org/hg/webcrypto-api/log
> 
> This bug contains many elements that are duplicate with already existing
> bugs (as you note), and so other elements of concern have been addressed
> separately, in those bugs.

As regards the larger issue of security recommendations,  see the messae from Virginie Gallindo:

http://lists.w3.org/Archives/Public/public-webcrypto/2014Jun/0130.html

I still think precise text (that we would need to formulate) would need to dealt with either via a reference or informative note (although possibly big red flag) in the "Securiy Considerations" section. Alternatively, we could try to revisit and re-open the per algorithm listing. Rich, do you any preference? 

We need a very concrete proposal, ideally with precise text changes. Would Graham or Kenny be able to make a text-level proposal?

(In reply to Harry Halpin from comment #13)
> The term "recommended" has caused continual confusion by the public in the
> two sense of recommendeed for implementation vs. recommended for new
> protocols. I believe one suggestion was to use "Suggested for interoperable
> implementation".
> Rich and Ryan, would that help?
> 
> So we could replace "18.2. Recommended algorithms" -> "18.2. Suggested
> algorithms for interoperability"
> 
> "Thus users of this API should check to see what algorithms are currently
> recommended and supported by implementations" ->
> "Thus users of this API should check to see what algorithms are currently
> supported by implementation. At the state of this publication,
> interoperability is given by the test-suite available at @@."
> 

Harry,

I would ask the same thing I asked of Rich: That you review the ED that was published and proposed as a resolution for this issue.

Your reference to 18.2 suggests you are looking at the WGLC, which is not really helpful for the discussion here.

For example, https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#algorithm-recommendations

"Recommendations
20.5.2 For Implementers

In order to promote interoperability for developers, this specification includes a list of suggested algorithms"

That is, the term "recommended algorithms" does not appear within the spec, as it stands, at all.

Additionally, a significantly expanded section in 20.5.1 has been added that clarifies, for authors, the need to read security considerations are. It incorporates all of the concerns raised on this bug, without the factually incorrect and misleading statement of "insecure".

Finally, the "Security Considerations" itself has been significantly beefed up, as described in https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#security-developers

And if that horse was not so thoroughly beaten to glue by now, as a result of this bug, the algorithm overview (link broken at the moment) contains yet another "scary warning" as a note - "Application developers and script authors should not interpret this table as a recommendation for the use of particular algorithms. Instead, it simply documents what operations are supported. Authors should refer to the Security considerations for authors section of this document to better understand the risks and concerns that may arise when using certain algorithms."

This is why, editorially, I believe this issue has been addressed, with the exception of the Security References, which I continue to assert is a pointless exercise.

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).

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.

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 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).

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.

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.

(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.

If that is the WG view, then the right thing to do is close this out as WONTFIX.

(In reply to Ryan Sleevi from comment #17)
> 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.

Rather than trying to ascribe motives here, I think everyone would benefit from this issue actually being discussed in the WG, full stop.

According to its home page, this WG hasn't had a meeting since 03 March (although I see unreferenced minutes in the archive from 05 May). There has been very little discussion of this issue on the mailing list beyond a back-and-forth between Ryan and Rich, despite the WG listing 70 participants in Good Standing. 

In fact, the only other WG discussion I can find on this issue (beyond Harry and Virginie's much-appreciated attempts to mediate an outcome) is Richard Barnes' comment:
  http://lists.w3.org/Archives/Public/public-webcrypto/2014May/0037.html
... which seems to support an addition along the lines that Rich proposed.

Did I miss something?

(In reply to Mark Nottingham from comment #19)
> (In reply to Ryan Sleevi from comment #17)
> > 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.
> 
> Rather than trying to ascribe motives here, I think everyone would benefit
> from this issue actually being discussed in the WG, full stop.

Mark,

Are you suggesting that a spec should include admonitions against/regarding something that it never once treats as part of the spec? Surely you can see how that seems strange.

Who would such advice be?
For authors? If so, the spec never once describes MD2 or MD5, so it is entirely out of context for authors - unless you consider it part of the spec's responsibility to describe how people should write secure protocols, something that I've objected to from the beginning (and which the spec itself recommends against).

For implementors? If so, the spec never once describes MD2 or MD5, so for implementors, it's not at all something that would ever come up.

It strikes me as entirely odd and incompatible with the idea of "scope" to suggest we should be discussing MD2/MD5, when the spec never once refers to it, and for which no one is advocating it be added.

Hey Ryan,

My comment was only on the operation of the WG in resolving this issue, not the issue itself.

Cheers,

(In reply to Rich Salz from comment #18)
> If that is the WG view, then the right thing to do is close this out as
> WONTFIX.

I tried to make it clear that I'm presenting an opinion as an individual.

However, regardless of your views, it seems worthwhile to note whether or not you agree with the classification of RSA-PSS as check-plus (can use SHA-1), RSA-OAEP as check-plus (vulnerable to Manger's attack), ECDSA as check-plus (vulnerable to nonce-reuse), ECDH as check-plus (vulnerable, as currently spec'd, to static DH problem), AES-GCM as check-plus (vulnerable to cache timing attacks in GHASH), AES-KW as check-plus (lacks formal security proof), HMAC as check-plus (can use SHA-1, regardless of the fact of RFC 6151's analysis) DH as check-plus (static-DH problem), Concat-KDF as check-plus (SHA-1), HKDF as check-plus (SHA-1), and PBKDF2 as check-plus (tradeoffs of parameters and the use of GPUs/ASICs, as it lacks a construction like scrypt-and-friends to make a memory/parallelization tradeoff, plus SHA-1)

If you don't feel that every algorithm would deserve a check-plus, then setting forth a formal criteria for when and where you believe that cryptographic attacks can be ignored or should be noted will be useful for the consistency of the spec, as well as to avoid future concerns of a formal objection.

Note my goal is to avoid the "living spec" requirements that such security considerations inherently bring.

If there's too much technical detail it will go over the heads of those who most need guidance.  If you want such detail, see the link in comment 9.

As for avoiding a 'living spec' kind of thing, that's the problem with security: it's all about trade-offs.  You can have a document for the ages that will never be wrong, but if absent advice of the moment can lead people astray. If that's what the WG wants, so be it. Others (see comment 7 for example) would disagree.

As for the criteria of which algorithms get marked and which don't: I based it on the advice of Paterson, Graham, Rogaway, NIST, and similar authorities. Backed up by the papers listed in the would-be security references section. If the WG wants to make more conservative choices, more power to them.

(In reply to Rich Salz from comment #23)
> If there's too much technical detail it will go over the heads of those who
> most need guidance.  If you want such detail, see the link in comment 9.

Well, this doesn't really set out who your target audience is for this, which is one of the criteria we'd need to actually, objectively, keep this up to date.

> 
> As for avoiding a 'living spec' kind of thing, that's the problem with
> security: it's all about trade-offs.  You can have a document for the ages
> that will never be wrong, but if absent advice of the moment can lead people
> astray. If that's what the WG wants, so be it. Others (see comment 7 for
> example) would disagree.
> 
> As for the criteria of which algorithms get marked and which don't: I based
> it on the advice of Paterson, Graham, Rogaway, NIST, and similar
> authorities. Backed up by the papers listed in the would-be security
> references section. If the WG wants to make more conservative choices, more
> power to them.

This again has problems. It lacks an objective criteria, other than "It's what would satisfy Rich's formal objection", which seems a very unfortunate state, for many reasons. All of the issues I mentioned have similar papers from similarly respected cryptographers, or which have similar nuance and caveats to the papers you referenced (which is not captured in the proposed language). This isn't about making "more conservative" choices - a statement which itself implies that there is a some criteria that you believe is neither "conservative" nor "liberal" - it's about trying to establish a set of objective criteria.

Without such criteria, I fear that every proposed algorithm would have to pass the "Rich Salz" test, which I doubt is your goal or intent, so you can see the benefit in establishing some criteria. I'm happy to dig up citations for you, but my point was to show that everything is with caveats, including things that are "in vogue" (e.g. the discussion of curves with respect to NIST, which itself has respected cryptographers on either side arguing about the relative security merits of the selected parameters)

If we don't have some way to cut this gordian knot of security considerations, we run the risk of being steered by the whim of every contributor, which is why I'm so adamant on the need to establish some criteria, and for proposals of language to have some criteria for which the proposals can be measured against, and for which the criteria - rather than the language - can be discussed on its merits.

This has once again become the "Rich and Ryan Show" and I'm sure everyone is tired of repeats of that. I look forward to hearing from the WG.

I believe I have commented before, so perhaps this does not answer Mark's request for comments from other WG members, but anyway.

First, the tone of discussion in this thread isn't exactly calculated to encourage participation. I don't see much evidence of either party acknowledging the points made by the other. There are valid points on both sides and it doesn't seem like it should be beyond us to construct a compromise that respects those points that are valid.

On the one hand, cryptography is like dynamite - it can move mountains but also bring one down on your head. It should come with a clear warning labels, especially when it is known that certain things can explode in certain unexpected ways.

On the other hand, our specification places normative requirements on the implementors of the specification, not on the users of the API. RFC2119 normative language with respect to the users of the API ('SHOULD not use...') makes no sense. It also makes no sense to refer to algorithms that are not supported at all by the specification. The specification should take great care not to mislead people into thinking that the dynamite is safe if only they follow our simple instructions.

Providing 'simple instructions' (for example a classification of 'safe' and 'unsafe' algorithms) is not only dangerous but, as Ryan has explained, extremely difficult to do with any degree of rigor. Any classification is highly application-dependent, nuanced and ultimately a matter of opinion (albeit well-respected opinion).

Ryan has provided a number of 'warning labels' in the specification. In my opinion, the remainder of this bug could be best addressed by:
(1) avoiding any attempt to summarize or simplify but instead provide direct references to the state-of-the-art with respect to the algorithms we support. Users of the API should be left in no doubt that they *need to understand* this material in all its gory detail in order to use the API with any degree of confidence
(2) do (1) in informative text, in a separate document that is clearly referenced from the API specification

We could also make it clearer in the specification that suggestions for implementors are NOT intended to be suggestions for users of the API and be very explicit that the API supports some algorithms with known weaknesses for the purpose of implementing legacy protocols and that users should study the document mentioned above before making algorithm choices.

(In reply to Mark Nottingham from comment #19)
> (In reply to Ryan Sleevi from comment #17)
> > 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.
> 
> Rather than trying to ascribe motives here, I think everyone would benefit
> from this issue actually being discussed in the WG, full stop.
> 
> According to its home page, this WG hasn't had a meeting since 03 March
> (although I see unreferenced minutes in the archive from 05 May). There has
> been very little discussion of this issue on the mailing list beyond a
> back-and-forth between Ryan and Rich, despite the WG listing 70 participants
> in Good Standing. 
> 
> In fact, the only other WG discussion I can find on this issue (beyond Harry
> and Virginie's much-appreciated attempts to mediate an outcome) is Richard
> Barnes' comment:
>   http://lists.w3.org/Archives/Public/public-webcrypto/2014May/0037.html
> ... which seems to support an addition along the lines that Rich proposed.
> 
> Did I miss something?

Mark,


The unreferenced minutes was from an informal chair/editors discussion. 

The Working Group, at the suggestion of the implementers, moved into what is known as a "bugzilla workmode". However, we will have a meeting, as stated by Virginie, to go through the all the proposals from Last Call where there has not been an agreed upon solution thought out. That meeting will happen after the July 12th deadline for textual changes, so there's still time to try to see if we can get some text everyone agrees on. 

I would note that (not sure if Rich noticed this) that his comments have had a very positive effect on the document. At least in the version I'm looking at, RSAES-PKCS1-v1.5 has been removed from even the "registered" algorithms.

(In reply to Harry Halpin from comment #27)
> I would note that (not sure if Rich noticed this) that his comments have had
> a very positive effect on the document. At least in the version I'm looking
> at, RSAES-PKCS1-v1.5 has been removed from even the "registered" algorithms.

Let's not get too excited. This removal was NOT in response to Rich's comments.

Best,
Ryan

Hi, I spoke with Harry briefly recently, and he told me an overview of this bug. Having seen how non-experts try to use cryptography libraries, I support the move to eventually deprecate non-authenticated modes of encryption.

I have a few concrete suggestions that don't seem to have been considered elsewhere yet:

A. Force modes like {CTR,CBC,CFB} to be paired with a MAC, by requiring the Algorithm object to include a subfield that specifies a mac Algorithm object.
B. Put those modes in yet another module, like window.crypto.subtle.old

I don't think it is so important to avoid "creat[ing] a point in time snapshot of a security state". This can be applied to *any* security spec that you might care to write about. Every spec has an implicit time-context, you have to expect future security implementors to understand this.

The alternative is to not commit to any advice about anything, instead giving vague recommendations to "RTF existing literature", which very few application authors will do.

"Any advice against is, implicitly, advice for" - a distinction should still be made between "maybe-bad" and "definitely-bad".

I do think it's a good idea to have separate documentation for implementors vs authors. No-one is in both roles, and putting both in the same document makes it more likely important advice will cause TL;DR. For example, things like "non-constant-time ECC curve implementations" is an implementation concern, whereas the abuse of {CTR,CBC,CFB} mode would be a concern for application authors.

One idea is that the some of the user-centric safety functions could be dealt with in a "high level" API, and putting per-algorithm security considerations in a separate document that can be updated outside of the progress of the spec. Would love opinions on them.

(In reply to Harry Halpin from comment #30)
> One idea is that the some of the user-centric safety functions could be
> dealt with in a "high level" API, and putting per-algorithm security
> considerations in a separate document that can be updated outside of the
> progress of the spec. Would love opinions on them.

Some pogress on the idea to reference a document listing attacks per algorithms, maintained by CFRG, via Wendy Seltzer http://lists.w3.org/Archives/Public/public-webcrypto/2014Jul/0098.html

Rich Salz and others,

   We think, given that the Working Group may have a finite lifespan and the crytographic landscape does indeed change, that the CFRG would be the right place to maintain the security considerations per algorithm.

   I would propose that once a suitable document is created as an IETF RFC, it would then be linked to the Web Crypto spec, with appropriate text to encourage developer to read the RFC. 

 Would an informational RFC, based on Graham and Rich's analysis but maintained by the CFRG, on security considerations per algorithm satisfy this comment without formal objection? 

      cheers,
          harry

As long as the WebCrypto document strongly encourages people to read the RFC, then yes it would.

(In reply to Rich Salz from comment #33)
> As long as the WebCrypto document strongly encourages people to read the
> RFC, then yes it would.

Can you please provide hypothetical language that you would believe satisfies this requirement? This bug has clearly documented that we have divergent views on "strongly", so sample language (and/or variations) would be appreciated.

Write it assuming such a doc exists, [FOO]

Gladly:
   This document describes an API but does not discuss security issues about using any particular algorithm. Authors and implementors SHOULD read the CFRG RFC on "FOO," the most current version, for such advice.

Not sure if "authors and implementors" is the right phrase -- whatever's in the document.  And SHOULD is IETF all-caps on purpose.

During 28th of July Web Crypto WG conference call, the following resolution was agreed by the WG : 
RESOLUTION: The WG to resolve the bug 25607 by (1) endorsing clarifications from the recent editors draft and (2) referencing to a document listing algorithms attacks and vulnerabilities, maintained by IETF CFRG (to be added in the specification by the editors as soon as available).

See http://www.w3.org/2014/07/28-crypto-minutes.html for more details.

As such the bug will stay open until the draft document referred to, is made available. 

Virginie
chair of web crypto wg

*** Bug 23501 has been marked as a duplicate of this bug. ***

*** Bug 18925 has been marked as a duplicate of this bug. ***

Note that Graham Steel's analysis has been converted into a IRTF CFRG report. 

Rich and others, we'd like your comments on this document and also we'll send it to CFRG for further discussion:

http://www.w3.org/2012/webcrypto/draft-irtf-cfrg-webcrypto-algorithms-00.xml

 As resolved, once adopted by CFRG the document can then be linked to the W3C Web Cryptography API as resolved earlier by the WG. 

The W3C (in the person of yours truly) has committed to maintaining the document at CFRG, which seems a better home for security analysis of algorithms than the Web Crypto API. 

   cheers,
      harry

The CFRG is now processing the latest version of the Security Considerations document (http://www.w3.org/2012/webcrypto/draft-irtf-cfrg-webcrypto-algorithms-00.txt), so we consider this bug "LATER" until the processing is finished, after which we can link to the CFRG-approved document.

(In reply to Harry Halpin from comment #40)
> The CFRG is now processing the latest version of the Security Considerations
> document
> (http://www.w3.org/2012/webcrypto/draft-irtf-cfrg-webcrypto-algorithms-00.
> txt), so we consider this bug "LATER" until the processing is finished,
> after which we can link to the CFRG-approved document.

Harry, from a process standpoint, it's not clear that the CFRG has accepted to work on this document, even as an informational note.

e.g. comments such as http://www.ietf.org/mail-archive/web/cfrg/current/msg05552.html or http://www.ietf.org/mail-archive/web/cfrg/current/msg05555.html suggest this is far from a resolved decision.

To the extent this issue is resolved, it's been punted, but the CFRG may (rightfully, especially in context of http://www.ietf.org/mail-archive/web/cfrg/current/msg05555.html ) decide not to work on this.

I think we've done the best we could by sending the document to CFRG for review, and the decision about whether or not to work on it depends on CFRG. As said earlier, edits will be done after initial comment period is over. There's also been a new ENISA report that needs to be double-checked before a new version is submitted.