Re: [Cfrg] pkcs#1v1.5

Russ Housley <housley@vigilsec.com> Sun, 23 March 2014 21:13 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430DD1A09F8 for <cfrg@ietfa.amsl.com>; Sun, 23 Mar 2014 14:13:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.13
X-Spam-Level:
X-Spam-Status: No, score=-101.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, USER_IN_WHITELIST=-100] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAcBsky3ikTJ for <cfrg@ietfa.amsl.com>; Sun, 23 Mar 2014 14:13:21 -0700 (PDT)
Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4641A09EA for <cfrg@irtf.org>; Sun, 23 Mar 2014 14:13:21 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 405589A43C1; Sun, 23 Mar 2014 17:13:11 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id j+isN7TjGK83; Sun, 23 Mar 2014 17:12:47 -0400 (EDT)
Received: from [192.168.5.215] (unknown [61.8.225.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 707DB9A43B5; Sun, 23 Mar 2014 17:12:45 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <CF535271.19584%kenny.paterson@rhul.ac.uk>
Date: Sun, 23 Mar 2014 17:12:36 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <14C0D5FC-4878-4E9D-85CA-C57CC77CB9AD@vigilsec.com>
References: <239D7A53E5B17B4BB20795A7977613A40207DB59F189@CROEXCFWP04.gemalto.com> <9cb524b6-c260-484e-bf44-45d52e7319a1@email.android.com> <CF522EF0.19491%kenny.paterson@rhul.ac.uk> <532D99CA.10405@cs.tcd.ie> <CF535271.19584%kenny.paterson@rhul.ac.uk>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
X-Mailer: Apple Mail (2.1085)
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/M8ms6k0_JSIsWy4pRrpLV1trF78
Cc: Virginie.GALINDO@gemalto.com, IRTF CFRG <cfrg@irtf.org>, IETF SAAG <saag@ietf.org>
Subject: Re: [Cfrg] pkcs#1v1.5
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Mar 2014 21:13:24 -0000

{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 <housley@vigilsec.com>
Date: December 4, 2013 5:40:33 AM EST
To: IETF SAAG <saag@ietf.org>
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 <housley@vigilsec.com>
Date: December 4, 2013 6:04:57 AM EST
To: IETF SAAG <saag@ietf.org>
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

= = = = = = = = =


On Mar 22, 2014, at 11:09 AM, Paterson, Kenny wrote:

> Hi
> 
> On 22/03/2014 14:10, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> 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" <stephen.farrell@cs.tcd.ie>
>>> wrote:
>>> 
>>>> -------- Original Message --------
>>>> From: GALINDO Virginie <Virginie.GALINDO@gemalto.com>
>>>> Sent: 21 March 2014 17:10:45 GMT+00:00
>>>> To: Jim Schaad <ietf@augustcellars.com>, "odonoghue@isoc.org"
>>>> <odonoghue@isoc.org>, "stephen.farrell@cs.tcd.ie"
>>>> <stephen.farrell@cs.tcd.ie>, "Kathleen.Moriarty.ietf@gmail.com"
>>>> <Kathleen.Moriarty.ietf@gmail.com>
>>>> Cc: Harry Halpin <hhalpin@w3.org>, "wseltzer@w3.org" <wseltzer@w3.org>
>>>> 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