This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In reference to, and as part of the recommendation received in, bug 25839, I'm creating this issue to request that: 1. The curves that are listed as unsafe in [1] be removed from the Named Curves. 2. Safe ones be recommended in their place (like Curve25519) 3. Should any Named Curves be discovered to be unsafe in the future, that they be deprecated and eventually removed from the spec.
Err, [1] refers to http://safecurves.cr.yp.to/
(In reply to Greg Slepak from comment #0) > In reference to, and as part of the recommendation received in, bug 25839, > I'm creating this issue to request that: > > 1. The curves that are listed as unsafe in [1] be removed from the Named > Curves. Presumably, [1] is http://safecurves.cr.yp.to/ The statement about "unsafe" is a statement with nuance that is not captured here. At [1], it's defined in the context of the set of criteria that the authors set out. Though reasonable, certainly true evaluation criteria, at the same time, their safety lacks known vulernabilities, and is widely deployed. There are significant inter-operability reasons to include the curves, least of all being the curves status within applications like TLS and X.509. > 2. Safe ones be recommended in their place (like Curve25519) We'll keep that for Bug 25839 > 3. Should any Named Curves be discovered to be unsafe in the future, that > they be deprecated and eventually removed from the spec. That's not going to happen, for the reasons captured (at great length) on https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985 . That's not how the web works.
(In reply to Ryan Sleevi from comment #2) > (In reply to Greg Slepak from comment #0) > > In reference to, and as part of the recommendation received in, bug 25839, > > I'm creating this issue to request that: > > > > 1. The curves that are listed as unsafe in [1] be removed from the Named > > Curves. > > Presumably, [1] is http://safecurves.cr.yp.to/ > > The statement about "unsafe" is a statement with nuance that is not captured > here. At [1], it's defined in the context of the set of criteria that the > authors set out. Though reasonable, certainly true evaluation criteria, at > the same time, their safety lacks known vulernabilities, and is widely > deployed. > > There are significant inter-operability reasons to include the curves, least > of all being the curves status within applications like TLS and X.509. Inter-operability should be broken for crypto that is insecure (this is not a comment about the security of the NIST-curves, but a general remark). > > 3. Should any Named Curves be discovered to be unsafe in the future, that > > they be deprecated and eventually removed from the spec. > > That's not going to happen, for the reasons captured (at great length) on > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985 . That's not how the > web works. Which reasons? There is a lot there (many reasons for various concerns). From https://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_2.0: > SSL 2.0 is disabled by default, beginning with Internet Explorer 7,[69] > Mozilla Firefox 2,[70] Opera 9.5,[71] and Safari. Maybe my wording is off a bit here, I just mean that broken crypto shouldn't be pushed onto browser vendors or anyone else. It shouldn't be introduced as part of new standards. To take one of the unsafe curves currently specified, secp256r1 has a questionable history [1]. What if it's found to be brute-forceable by a supercomputer within a small time frame? Will you still keep supporting it in your spec and thereby endangering the security of the net? [1] http://beta.slashdot.org/story/191445
(In reply to Greg Slepak from comment #3) > Inter-operability should be broken for crypto that is insecure (this is not > a comment about the security of the NIST-curves, but a general remark). It's hard to see how you're not making it a comment on the NIST-curves, since you're arguing they should be removed. The only reason for removing would be if you view them as insecure. If you do view them as insecure, well, that's an opinion that is still highly subjective within the cryptographic community, [1] aside. > > > 3. Should any Named Curves be discovered to be unsafe in the future, that > > > they be deprecated and eventually removed from the spec. > > > > That's not going to happen, for the reasons captured (at great length) on > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985 . That's not how the > > web works. As noted on that thread, removing APIs from the web (which breaks sites) is far, far more troubling and difficult. Referencing SSL 2.0 is entirely orthogonal to the discussion. This would be akin to the next draft of HTML removing support for the canvas tag entirely. Just because you removed it from your spec doesn't magically make it stop existing, nor does it remove browsers' need to support it, as pages live on. The history of HTML - and in the Web in general - is that APIs are not deprecated. Period. And so far, it's been a good story. > To take one of the unsafe curves currently specified, secp256r1 has a > questionable history [1]. What if it's found to be brute-forceable by > a supercomputer within a small time frame? Will you still keep supporting > it in your spec and thereby endangering the security of the net? Let's keep the excitement to a minimum, and the objectivity at a balanced level. "Thereby endangering the security of the net" is a statement that can be shown to be demonstrably false, and is at best an emotional appeal. It is application developers, not user agents, that are best capable of evaluating their appropriate requirements for security and interoperability. Web Crypto simply provides those tools. The statements about backdoors have so far shown to be without merit, but are equally unquestionable a matter of subjectivity within the cryptographic community. We can appeal to experts on either side - those that view they are backdoored, and those that are not. Generally speaking, the claims of backdoors have been significantly overstated, as it relates to the DLP. However, if we set that aside for a second, there are clearly a number of use cases, today, right now, for the use of the NIST curves. The fact that every standards-based system uses them is chief among them. Stating these use cases are invalid for WebCrypto is a subjective opinion, and one that does no one - user agent vendors, authors, or users - any favors. If you still truly believe that the use of these curves endangers the security of the net (an opinion I would strongly disagree with you), even if you feel these use cases are out of luck (which would go against our charter, arguably), you'd be far better protecting the net by getting them out of TLS and X.509, since that's the basis of all the user agent security promises to begin with. If they are insecure, then NOTHING built on WebCrypto can be secure, since they'd be on an insecure transport.
(In reply to Ryan Sleevi from comment #4) > Referencing SSL 2.0 is entirely orthogonal to the discussion. This would be > akin to the next draft of HTML removing support for the canvas tag entirely. > Just because you removed it from your spec doesn't magically make it stop > existing, nor does it remove browsers' need to support it, as pages live on. > > The history of HTML - and in the Web in general - is that APIs are not > deprecated. Period. And so far, it's been a good story. Two things: 1. See no longer rendered <BLINK> tag. 2. I acknowledged this is mostly true when I said "Maybe my wording is off a bit here, I just mean that broken crypto shouldn't be pushed onto browser vendors or anyone else." > Let's keep the excitement to a minimum, and the objectivity at a balanced > level. "Thereby endangering the security of the net" is a statement that > can be shown to be demonstrably false, and is at best an emotional appeal. > It is application developers, not user agents, that are best capable of > evaluating their appropriate requirements for security and interoperability. > Web Crypto simply provides those tools. This bug started as an offshoot of bug 25839, where I was told (by you) in not precisely these words, that the Web Crypto API is not recommending that specific curves be implemented. I wouldn't have created this bug if your spec offered a single safe curve, but it does not, so it can be argued that the "tools" it's providing aren't very good (currently). Hopefully a safe curve(s) will be added to the spec soon. > If you still truly believe that the use of these curves endangers the > security of the net (an opinion I would strongly disagree with you), even if > you feel these use cases are out of luck (which would go against our > charter, arguably), you'd be far better protecting the net by getting them > out of TLS and X.509, since that's the basis of all the user agent security > promises to begin with. If they are insecure, then NOTHING built on > WebCrypto can be secure, since they'd be on an insecure transport. It would be better for me to file this bug for TLS (wherever that would be), that's probably true. That doesn't mean, however, that in all cases the security of WebCrypto is limited by TLS (for example, browser extensions that store pinned certs or fingerprints locally would clearly have security exceeding that of TLS + X.509). A look forward for more (safer) curve diversity in the spec, and hope it makes it into the 1.0 (or w/e you call your final release).
(In reply to Greg Slepak from comment #5) > 1. See no longer rendered <BLINK> tag. Only worked because it was only one UA. And, FWIW, the HTML5 spec still describes how to parse it. > This bug started as an offshoot of bug 25839, where I was told (by you) in > not > precisely these words, that the Web Crypto API is not recommending that > specific > curves be implemented. WebCrypto IS normatively requiring that, if ECDSA or ECDH are supported as algorithms, the curves specified MUST be supported. WebCrypto is NOT requiring that ECDSA or ECDH are supported. > I wouldn't have created this bug if your spec offered a single safe curve, > but it does not, so it can be argued that the "tools" it's providing aren't > very good (currently). Hopefully a safe curve(s) will be added to the spec > soon. The misnomer of "safe curve" will continue to cause confusion. Truly unfortunate. > That doesn't mean, however, that in all cases the security of WebCrypto is > limited by TLS (for example, browser extensions that store pinned certs or > fingerprints locally would clearly have security exceeding that of TLS + > X.509). Extensions updated via TLS? That are signed with { RSA or ECDSA-using-the-NIST-curves }? Which are both UA-specific implementation details? > > A look forward for more (safer) curve diversity in the spec, and hope it > makes > it into the 1.0 (or w/e you call your final release). That is unlikely.
(In reply to Ryan Sleevi from comment #6) > (In reply to Greg Slepak from comment #5) > > This bug started as an offshoot of bug 25839, where I was told (by you) in > > not > > precisely these words, that the Web Crypto API is not recommending that > > specific > > curves be implemented. > > WebCrypto IS normatively requiring that, if ECDSA or ECDH are supported as > algorithms, the curves specified MUST be supported. > > WebCrypto is NOT requiring that ECDSA or ECDH are supported. Thanks for clearing that up. > > I wouldn't have created this bug if your spec offered a single safe curve, > > but it does not, so it can be argued that the "tools" it's providing aren't > > very good (currently). Hopefully a safe curve(s) will be added to the spec > > soon. > > The misnomer of "safe curve" will continue to cause confusion. Truly > unfortunate. A misnomer? You're saying DJB was wrong to call them unsafe? > > That doesn't mean, however, that in all cases the security of WebCrypto is > > limited by TLS (for example, browser extensions that store pinned certs or > > fingerprints locally would clearly have security exceeding that of TLS + > > X.509). > > Extensions updated via TLS? That are signed with { RSA or > ECDSA-using-the-NIST-curves }? Which are both UA-specific implementation > details? Valid concerns. It might be possible for extensions to attempt to mitigate against updates, but those are implementation and US-specific details. > > > > A look forward for more (safer) curve diversity in the spec, and hope it > > makes > > it into the 1.0 (or w/e you call your final release). > > That is unlikely. I hope nobody uses the spec then.
(In reply to Greg Slepak from comment #7) > > > A look forward for more (safer) curve diversity in the spec, and hope it > > > makes > > > it into the 1.0 (or w/e you call your final release). > > > > That is unlikely. > > I hope nobody uses the spec then. That came off meaner than I intended. I meant: I hope nobody uses that part of the spec. Obviously, some might have no choice if they want to support unsafe or insecure protocols, but they are putting their users at risk doing so.
(In reply to Ryan Sleevi from comment #4) > (In reply to Greg Slepak from comment #3) > > > > 3. Should any Named Curves be discovered to be unsafe in the future, that > > > > they be deprecated and eventually removed from the spec. > > > > > > That's not going to happen, for the reasons captured (at great length) on > > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985 . That's not how the > > > web works. > > As noted on that thread, removing APIs from the web (which breaks sites) is > far, far more troubling and difficult. > > Referencing SSL 2.0 is entirely orthogonal to the discussion. This would be > akin to the next draft of HTML removing support for the canvas tag entirely. > Just because you removed it from your spec doesn't magically make it stop > existing, nor does it remove browsers' need to support it, as pages live on. I think more needs to be discussed about this point, as the more I think about it the more I think you are conflating two incompatible concepts that should not be conflated. These two mutually exclusive concepts are: Type 1: Something like the HTML spec, which specifies how pages are to be displayed (usually visually). Type 2: How pages are to be transmitted. What you're building here is not of Type 1. You are making something like SSL, a security spec, and security specs definitely do contain the concept of "deprecation", etc. There is *no point* in making an insecure security spec. That would be, how you say, an oxymoron. Security-specs *must* support deprecation. There is no point to them otherwise. On a somewhat related note, look what happened to CSS :visited attributes when it was discovered that they can be used by JavaScript to enumerate a user's browsing history: https://blog.mozilla.org/security/2010/03/31/plugging-the-css-history-leak/ They were mutated to prevent that from happening.
(In reply to Greg Slepak from comment #9) To sumup the current status of the WG discussions with respect to your initial bug demand: 1. The curves that are listed as unsafe in [1] be removed from the Named Curves. --> the WG discussed during several months the list of algorithms described in that spec, removing something is not something we are ready to do at the moment. 2. Safe ones be recommended in their place (like Curve25519) --> This is currently discussed in the bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839 3. Should any Named Curves be discovered to be unsafe in the future, that they be deprecated and eventually removed from the spec. --> This is currently discussed in the bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607. A possible resolution could be to reference a document listing the known algorithms weaknesses. With respect to that status, I suggest that we close the bug as WONTFIX (while addressing your point #2 and #3, we wont fix #1). Virginie Chair of the Web Crypto WG
(In reply to virginie.galindo from comment #10) > (In reply to Greg Slepak from comment #9) > > To sumup the current status of the WG discussions with respect to your > initial bug demand: > 1. The curves that are listed as unsafe in [1] be removed from the Named > Curves. > --> the WG discussed during several months the list of algorithms described > in that spec, removing something is not something we are ready to do at the > moment. > > 2. Safe ones be recommended in their place (like Curve25519) > --> This is currently discussed in the bug > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839 > > 3. Should any Named Curves be discovered to be unsafe in the future, that > they be deprecated and eventually removed from the spec. > --> This is currently discussed in the bug > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607. A possible resolution > could be to reference a document listing the known algorithms weaknesses. > > With respect to that status, I suggest that we close the bug as WONTFIX > (while addressing your point #2 and #3, we wont fix #1). > > Virginie > Chair of the Web Crypto WG That seems fair. Feel free to mark this bug as such. :)
As per decision from the Web Crypto WG, based on team feedbacks and bug reviewer feedbacks, this bug is resolved as WONTFIX. Virginie chair of web crypto wg