Re: [TLS] RSA-PSS in TLS 1.3

mrex@sap.com (Martin Rex) Fri, 04 March 2016 13:45 UTC

Return-Path: <mrex@sap.com>
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 969031A00B5 for <tls@ietfa.amsl.com>; Fri, 4 Mar 2016 05:45:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.551
X-Spam-Level:
X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
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 BmFEde7J82FU for <tls@ietfa.amsl.com>; Fri, 4 Mar 2016 05:45:17 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB1F1A00B1 for <tls@ietf.org>; Fri, 4 Mar 2016 05:45:17 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 7C8062A97C; Fri, 4 Mar 2016 14:45:14 +0100 (CET)
X-purgate-ID: 152705::1457099114-00007292-A7062D6A/0/0
X-purgate-size: 1788
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 457F340C14; Fri, 4 Mar 2016 14:45:14 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id EED9E1A45C; Fri, 4 Mar 2016 14:45:13 +0100 (CET)
In-Reply-To: <20160229190021.59516808@pc1>
To: Hanno Böck <hanno@hboeck.de>
Date: Fri, 04 Mar 2016 14:45:13 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20160304134513.EED9E1A45C@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/1hKtF4Hutlsr3m3_AFE8SQo9ciQ>
Cc: tls@ietf.org
Subject: Re: [TLS] RSA-PSS in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: <https://mailarchive.ietf.org/arch/browse/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, 04 Mar 2016 13:45:19 -0000

Hanno Böck wrote:
> Joseph Salowey <joe@salowey.net> wrote:
>> 
>> We make RSA-PSS mandatory to implement (MUST implement instead of MUST
>> offer).   Clients can advertise support for PKCS-1.5 for backwards
>> compatibility in the transition period.
>> Please respond on the list on whether you think this is a reasonable
>> way forward or not.
> 
> I recently already saw the message here asking for PKCS #1 1.5
> compatibilty and was quite angry about it, but as there wasn't much
> discussion I thought this issue would go away. It seems it did not.
> 
> RSA-PSS was specified as RFC 3447 in 2003. That was 13 years ago.

RSA-PSS signatures are crap, and they're pretty close to useless.

What should have adopted for TLSv1.2 already, however, is the less
forgiving PKCS#1 v1.5 signature check, that re-creates the encoding
and then compares the recreated inner encoding with the RSA-decrypted
encoding only.  Get rid of the de-padding and get rid of the ASN.1
decoding of the contents.  This is also the recommended fashion
for PKCS#1 v1.5 signature verification in rfc3447.


The *huge* advantage of PKCS#1 v1.5 signatures over RSA-PSS and ECDSA
signatures is that one can clearly distinguish "wrong public key"
from "signature does not fit plaintext" errors, and loosing this
capability makes certain kinds of programming goofs (plus a few
admin configuration goofs) much harder to distinguish from
data corruption during transfer.  XMLdsig and XML canonicalization
is another source of endless fun, where being able to distinguish
these causes for signature verification failure facilitates
troubleshooting.


Signature verification itself is a public key operation, so RSA-PSS
is a wholly different beast than RSA-OAEP.


-Martin