Subject: [saag] Fwd: W3C Web Crypto API - moving to Last Call

From: Stephen Farrell <[email-masked]>
Date: Fri, 21 Mar 2014 17:54:45 +0000

-------- Original Message --------
From: GALINDO Virginie <[email-masked]>
Sent: 21 March 2014 17:10:45 GMT+00:00
To: Jim Schaad <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Harry Halpin <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: W3C Web Crypto API - moving to Last Call

Hi IETF and JOSE team,

The Web Cryptography Working Group has decided to go to Last Call for the Web Cryptography API next week. We'd like to make sure your group has enough time to review the specification. Is four weeks enough time? If I don't hear back from you, I am going to assume it is enough time. Our latest draft is here:

https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html

Regards,

Virginie Galindo

Gemalto

chair of W3C web crypto wg

________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus

---

From: "Paterson, Kenny" <[email-masked]>
Date: Fri, 21 Mar 2014 18:15:34 +0000

Hi Stephen,

[Cross-posting to CFRG, since it seems relevant]

On 21/03/2014 17:54, "Stephen Farrell" <[email-masked]> wrote:

>To: Jim Schaad <[email-masked]>, "[email-masked]"
><[email-masked]>, "[email-masked]"
><[email-masked]>, "[email-masked]"
><[email-masked]>
>The Web Cryptography Working Group has decided to go to Last Call for the
>Web Cryptography API next week. We'd like to make sure your group has
>enough time to review the specification. Is four weeks enough time? If I
>don't hear back from you, I am going to assume it is enough time. Our
>latest draft is here:
>
>
>

Tibor Jager, Juarj Somorovsky and I sent this team feedback some time ago
about the undesirability of standardising already-broken algorithms and
modes (e.g. PKCS#1v1.5 encryption, CBC-mode encryption with no integrity
protection). 

This was in response to a request for feedback from CFRG. We gave them
chapter and verse (and citations) about why this is generally a BAD IDEA:

http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0186.html

The broken algorithms and modes are still in the Web Crypto document.
Moreover, there are no relevant warnings about these broken algorithms and
modes in the "security considerations" section of the current Web Crypto
draft.

Needless to say, I'm not minded to provide any more free advice to this
group.

Cheers,

Kenny

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 21 Mar 2014 14:55:50 -0400

Their response seems to have been "we're designing an API for folks who understand the issues."
(e.g., http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0189.html)

That seems naïve to me.

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 22 Mar 2014 14:10:18 +0000

Hi Kenny,

> [Cross-posting to CFRG, since it seems relevant]

[reducing back to saag, see below for why:-) ]

> Tibor Jager, Juarj Somorovsky and I sent this team feedback some
> time ago about the undesirability of standardising already-broken
> algorithms and modes (e.g. PKCS#1v1.5 encryption, CBC-mode
> encryption with no integrity protection).

Not sure I'd agree with "broken" there, other than from a theoretical
POV. Old/weaker/sniffy and not state-of-the-art would be fair though.
In any case, yes, there's better crypto primitives to be used.

But there's an ongoing topic here that might be worth a thread - how to
move beyond pkcs#1v1.5 and other mechanisms with known crypto issues
(whether currently practical or not) but where there's *huge*
deployment and many many implementations in use in the wild on all
sorts of platforms.

I don't know how we can improve that situation (since a lot of this is
not controlled by the IETF or W3C) but I do know a lot of security
folks would like it if we could.

Unfortunately, history seems to show that it requires a very-near-
practical break before implementations and deployments will change in
sufficient numbers. And maybe it also requires the non-existence of
a band-aid that can be applied at another protocol or s/w layer.

And of course this problem is really nothing to do with the crypto
but is all about implementations and deployments. (Hence dropping
cfrg cross-post:-)

But ideas welcome...

Cheers,
S.

PS: On the w3c spec: yes, it'd seem entirely reasonable to warn about
known issues and e.g. say that we do expect to move away from these at
some point. That's a good comment. I'm surprised if they blew that
off.

---

From: "Paterson, Kenny" <[email-masked]>
Date: Sat, 22 Mar 2014 15:09:50 +0000

Hi

>[reducing back to saag, see below for why:-) ]

[re-cross-posting to cfrg, see below for why]

>In any case, yes, there's better crypto primitives to be used.

Well, unauthenticated encryption (e.g. CBC mode) has been broken *in
practice* in many real-world systems, including, for example IPsec
(starting with Bellovin's work, but reaching its nadir in my work with
Degabriele from IEEE S&P 2007) and XML encryption (Jager and Somorovsky,
ACM-CCS 2011). 

The Bleichenbacher "million message" attack against PKCS#1v1.5 encryption
was significantly improved in a paper at Crypto 2012 by Bardou et al., and
applied to a variety of security tokens and a fielded HSM. Practical
attacks against XML encryption based on the known weaknesses in PKCS#1v1.5
were demonstrated by Jager et al at ESORICS 2012.

So several of the schemes being proposed for standardisation for general
purpose use in this WebCrypto standard have already been broken *in
practice* and *several times over*. It seems foolhardy to be including
them in a new standard, irrespective of the "facts on the ground"
concerning their deployment.

>deployment and many many implementations in use in the wild on all

I agree, this is important. But putting the already broken schemes in a
new standard does not seem helpful in that regard.

>a band-aid that can be applied at another protocol or s/w layer.

And what a sad state of affairs that is.

The history of, for example, chained IVs in SSL/TLS should be salutary
lesson in the folly of this approach. There, Rogaway already presented a
theoretical attack in 1995. It was explained how this could be exploited
to recover plaintext in 2006 by Bard, but without a working attack.
Finally, the SSL/TLS community got its backside badly bitten by BEAST in
2011, which basically took Bard's attack and showed how to realise it in
the web setting. Cue much panic and hand-wringing. Well, everybody was
warned...

>but is all about implementations and deployments. (Hence dropping

These issues should be a first class concern for cfrg. There are serious
research questions at stake here. Like: how do we build developer-proof
APIs; how do we retire protocols, modes, algorithms which are showing
signs of weakness; how do we automatically find crypto bugs, side
channels, and the like, and eliminate them.

>But ideas welcome...

Here's one idea: make sure that a new standard does not include broken
algorithms and modes. Then, to be able to claim compliance with the
standard, existing deployments will have to get their house in order.

Here's another: let's set up an aggressive timescale for deprecation of
SSLv3, TLS 1.0 and TLS 1.1.

>some point. That's a good comment. I'm surprised if they blew that

They seem to have pretty much blown it off. Check out the specification's
security considerations section:

http://www.w3.org/TR/WebCryptoAPI/#security

"This API includes a variety of cryptographic operations, some of which
may have known security issues when used inappropriately. Application
developers should take care to review the appropriate cryptographic
literature before making use of certain algorithms, and should avoid
attempting to develop new cryptographic protocols whenever possible."

For me, this is not nearly stark or specific enough. What is the average
developer meant to make of it?

Cheers

Kenny

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 22 Mar 2014 14:30:58 -0400

> I agree, this is important. But putting the already broken schemes in a new standard does not seem helpful in that regard.

It's a  new API.  It's not a standardization of something that already exists, it's a brand new whole-cloth invention of something that did not exist before.  And yet, we're going to allow developers to create broken data.  "Does not seem helpful" is really understatement.

Perhaps they can create read-only bindings for these insecure structures?

Perhaps, as a gedanken experiment, I can propose a generalization of the symmetric encryption algorithm rot-13, which has a huge historical legacy via Usenet? The security considerations are pretty simple: "do not choose number of rounds (n) and shift size (s) such that n*s is zero mod 26."  That would seem to meet all the requirements of the current draft.

	/r$

---

From: Harry Halpin <[email-masked]>
Date: Sun, 23 Mar 2014 15:53:52 +0100

> but is all about implementations and deployments. (Hence dropping

We are very happy to take this feedback on, however - I recommend you 
forward it to [email-masked] so it can be publically 
recorded by the W3C. While I'm on SAAG list, not everyone in the 
WebCrypto WG is and so we may miss comments.

Note that there was a tension in the Crypto API between 
backwards-compatibility with popular crypto already implemented in the 
browser and ensuring only "safe" crypto will be used. The WG went 
towards the former path, but would be happy to hear arguments towards 
the latter.

    cheers,
       harry

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Watson Ladd <[email-masked]>
Date: Sat, 22 Mar 2014 14:11:51 -0700

> Perhaps, as a gedanken experiment, I can propose a generalization of the symmetric encryption algorithm rot-13, which has a huge historical legacy via Usenet? The security considerations are pretty…

Let's be even clearer: there is no reason why crypto_box(pubkey,
seckey, message, nonce, assoc_data) cannot be provided in the API as a
safe combination of the primitives already existing, but the current
draft ignores what application developers actually want. By providing
subtle_crypto the authors are saying that PKCS 1.5 and AES-CBC aren't
problems, but AES-CTR is. (This is actually said in the current
draft). By failing to provide a safe alternative to roll your own,
they are asking developers who don't know anything about crypto to
play a Choose-Your-Own-Adventure novel where most paths end with
death.

This is the wrong approach to take. If the current draft is
implemented, expect thousands of of badly broken applications to be
built on top if it. It should be difficult to do the wrong thing, and
easy to do the right thing, but this API takes the opposite approach.

Sincerely,
Watson Ladd
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Russ Housley <[email-masked]>
Date: Sun, 23 Mar 2014 17:12:36 -0400

{top post}

Last December, on two separate SAAG mail list threads, I suggested that we begin the migration to RSA-OAEP and RSA-PSS.  I have copied the first message in each of those threads below to save folks time with the mail archive search.  I continue to believe that we should begin this migration.

It takes a really long time to make such a transition.  Let's get started today.

Russ

= = = = = = = = =

From: Russ Housley <[email-masked]>
Date: December 4, 2013 5:40:33 AM EST
To: IETF SAAG <[email-masked]>
Subject: [saag] RSA-OAEP

We have known for a very long time that PKCS #1 Version 1.5 (see RFC 2313) key transport is vulnerable to adaptive chosen ciphertext attacks.  Exploitation reveals the result of a particular RSA decryption, requires access to an oracle which will respond to a hundreds of thousands of ciphertexts, which are constructed adaptively in response to previously-received replies providing information on the successes or failures of attempted decryption operations.  As a result, the attack appears significantly less feasible in store-and-forward environments than interactive ones.

PKCS #1 Version 2.0 and Version 2.1 (see RFC 3447) include RSA-OAEP to address this situation, but we have seen very little movement toward RSA-OAEP.  While we are reviewing algorithm choices in light of the pervasive surveillance situation, I think we should take the time to address known vulnerabilities like this one.  If we don't, then we are leaving an partially open door for a well funded attacker.

Russ

= = = = = = = = = = 

From: Russ Housley <[email-masked]>
Date: December 4, 2013 6:04:57 AM EST
To: IETF SAAG <[email-masked]>
Subject: [saag] RSA-PSS

We have known for a very long time that PKCS #1 Version 1.5 (see RFC 2313) signature is more fragile than we might like.  PKCS #1 Version 1.5 signatures were developed in an ad hoc manner; RSASSA-PSS as specified in PKCS #1 Version 2.1 (see RFC 3447) was developed based on mathematical foundations.

I am aware of two attacks against PKCS #1 Version 1.5 implementations:

First, the Bleichenbacher attack against implementations.  In this attack, implementations do not calculate the length of the padding, but rather scan the 0xff at the beginning until they find a 0x00 byte.  Also, a small RSA exponent (for example e=3).

Second, fault-based attacks described by Boneh and others.  By injecting random faults into the RSA calculations, the attacker is able to regenerate the private key from the knowledge of faulty signatures.

RSA-PSS offers significant improvement against both of these attacks.

We have seen very little movement toward RSA-PSS.  While we are reviewing algorithm choices in light of the pervasive surveillance situation, I think we should take the time to consider improvements in our algorithm choices.

Russ

= = = = = = = = =

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 24 Mar 2014 15:00:29 +0100

6 months ago, I raised the question on the tls mailing list, if we shouldn't allow usage of RSA-PSS signatures in TLS.
There was almost no support for that idea and the arguments I faced were
 - The need to support both legacy RSA and RSA-PSS introduces considerable complexity, in particular, if we try to reuse
existing cipher suites
 - PSS doesn't give much benefit over PKCS#1v1.5. As Peter Gutmann put it: "I know
it's *theoretically* better, but unless you do -1.5 really badly there's no
practical weakness that would encourage an upgrade."

I was told that there was an attempt, some years ago, to mandate RSA-PSS for certificates.  It was met with pretty much
universal rejection, to the extent that people would probably ignore the requirement even if it was made a MUST in the
spec and as a result was dropped.

Clearly the issue with PKCS#1v1.5 encryption is worse, so there might be more urge to migrate to OAEP. As development of
TLS 1.3 is just about to start, this might be the right time.

Johannes