Comments from SAAG on Last Call [Fwd: Re: [saag] pkcs#1v1.5]

Just in case people missed this, here's the comments from some of the 
folks on the SAAG on WebCrypto and copied by folks in CFRG (see previous 
emails/discussion with them)  about how we should not encourage PKCS 1.5 
and CBC without integrity. In general, there was worry around attacks on 
PKCS #1 Version 1.5, so the thread became a thread about how to migrate 
to RSA-PSS.

In particular, Kenny Paterson from CFRG feels that we "blew off" his 
comments so that "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."

I see one response

1) We should simply state that we cannot at this time remove CBC and all 
PKCS 1.5 as there are use-cases that require them. We can also explain 
how we don't want our Security Considerations Section to end of trying 
to track the crypto literature, although we should add some sentences to 
clarify the difference between "registered" (i.e. wellformed and 
implemented) and "recommended" (i.e. recommended for new protocols). 
We're still pretty vague on "recommended" algorithms.

And two possible additional responses:

2) The easiest answer is probably to clarify whether or not they want 
RSASSA-PKCS1-v1_5 using SHA-1 removed from recommended and note that 
RSAES-PKCS1-v1_5 is already not recommended.

3) The one that requires more work from them is that we ask CFRG to 
begin the task of surveying algorithms and explicitly maintain a list of 
algorithms they don't want to see developers use. We will keep any of 
these algorithms out of "recommended" list (18.2) in our spec, but we 
will still let people use them for backwards-compatibility and put them 
in the registered algorithm list of 18.1, as well as intest-suite.


    cheers,
       harry


-------- Original Message --------
Subject: 	Re: [saag] pkcs#1v1.5
Date: 	Sun, 23 Mar 2014 17:12:36 -0400
From: 	Russ Housley <housley@vigilsec.com>
To: 	Paterson, Kenny <Kenny.Paterson@rhul.ac.uk>
CC: 	Virginie.GALINDO@gemalto.com, IRTF CFRG <cfrg@irtf.org>, IETF SAAG 
<saag@ietf.org>



{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

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag