Re: [TLS] Using RSA PSS in TLS

Manuel Pégourié-Gonnard <mpg@polarssl.org> Fri, 16 January 2015 12:52 UTC

Return-Path: <mpg@polarssl.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23011ACDC8 for <tls@ietfa.amsl.com>; Fri, 16 Jan 2015 04:52:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.096
X-Spam-Level: *
X-Spam-Status: No, score=1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.793, SPF_PASS=-0.001] 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 HwGiKVOVIS7S for <tls@ietfa.amsl.com>; Fri, 16 Jan 2015 04:52:30 -0800 (PST)
Received: from vps2.offspark.com (unknown [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93EAD1ACDCF for <tls@ietf.org>; Fri, 16 Jan 2015 04:52:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=offjyzz+Vjs3VaV+MWSW/eo1MYf0B3ZMT5n7q4fkIs0=; b=K3qfr5NGOAOmAmICrHToFF68RwnKEMXOeCwQXzYtCQlG5duaBygan5e+Knk4zJSnBoTWTzqml6+Ry5LA2l8X4avzVHhMgrIpq5c/ze+GLyxPUTUGeapKKbpKv5sXFkkCVNZzukaYoWjOT8MkrCOD/HQz3L5E4Fh0MwG5Gpiv/XA=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1YC6Nr-0000Iz-0h; Fri, 16 Jan 2015 13:52:15 +0100
Message-ID: <54B90989.1030401@polarssl.org>
Date: Fri, 16 Jan 2015 13:52:25 +0100
From: Manuel Pégourié-Gonnard <mpg@polarssl.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Geoffrey Keating <geoffk@geoffk.org>, mrex@sap.com
References: <20150115013149.0185bea4@pc> <20150115005032.1FBC41B0EA@ld9781.wdf.sap.corp> <m21tmw3i9l.fsf@localhost.localdomain>
In-Reply-To: <m21tmw3i9l.fsf@localhost.localdomain>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/GwF9glOQpRBz7EsWwk8EB3x1nXw>
Cc: tls@ietf.org
Subject: Re: [TLS] Using RSA PSS in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Jan 2015 12:52:32 -0000

On 15/01/2015 03:11, Geoffrey Keating wrote:
> mrex@sap.com (Martin Rex) writes:
> 
>> If the spec was tightened to prohibit *all* kinds of parsing
>> of the RSA-decrypted BT01 padding signature plaintext,
>> and instead required rebuilding of the BT01 padding from the input hash
>> value and input hash oid, and comparison of the newly composed result
>> with what the RSA decryption returned, then none of the parser problems
>> for RSA PKCS#1 v1.5 signatures would have existed.
>>
>> That approach to RSA signature verification is actually the one
>> recommended by PKCS#1 v2.1 for the RSASSA-PKCS1-V1_5-VERIFY operation.
>>
>>   https://tools.ietf.org/html/rfc3447#section-8.2.2
> 
> Would this actually work?  I suspect implementations use slightly
> inconsistent padding generation...
> 
Appparently [1] NSS and BoringSSL has been doing that for a few months now
(though NSS seems to take steps to allow some variation), maybe they could
provide some feedback?

[1]: https://www.imperialviolet.org/2014/09/26/pkcs1.html

Manuel