Re: [Cfrg] pkcs#1v1.5 (was: Re: [saag] Fwd: W3C Web Crypto API - moving to Last Call)

["Paterson, Kenny" <[e-mail]>]

Hi

On 22/03/2014 14:10, "Stephen Farrell" <[e-mail]> wrote:
>
>Hi Kenny,
>
>On 03/21/2014 06:15 PM, Paterson, Kenny wrote:
>> Hi Stephen,
>> 
>> [Cross-posting to CFRG, since it seems relevant]
>
>[reducing back to saag, see below for why:-) ]

[re-cross-posting to cfrg, 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.

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.


>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 agree, this is important. But putting the already broken schemes in a
new standard does not seem helpful in that regard.

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

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

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.

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

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


>
>> 
>> On 21/03/2014 17:54, "Stephen Farrell" <[e-mail]>
>>wrote:
>> 
>>> -------- Original Message --------
>>> From: GALINDO Virginie <[e-mail]>
>>> Sent: 21 March 2014 17:10:45 GMT+00:00
>>> To: Jim Schaad <[e-mail]>, "[e-mail]"
>>> <[e-mail]>, "[e-mail]"
>>> <[e-mail]>, "[e-mail]"
>>> <[e-mail]>
>>> Cc: Harry Halpin <[e-mail]>, "[e-mail]" <[e-mail]>
>>> 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
>>>
>> 
>> 
>> 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 
>> 
>> 
>> 
>> 
>