Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.txt

Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 27 March 2017 07:24 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FEC12941C for <curdle@ietfa.amsl.com>; Mon, 27 Mar 2017 00:24:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Oe7bcphlEkNf for <curdle@ietfa.amsl.com>; Mon, 27 Mar 2017 00:24:53 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3A71293DA for <curdle@ietf.org>; Mon, 27 Mar 2017 00:24:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 4D9F624AF4; Mon, 27 Mar 2017 10:24:50 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id cpK41sVEIfLS; Mon, 27 Mar 2017 10:24:49 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id CB02221C; Mon, 27 Mar 2017 10:24:49 +0300 (EEST)
Date: Mon, 27 Mar 2017 10:24:48 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: denis bider <denisbider.ietf@gmail.com>, "curdle@ietf.org" <curdle@ietf.org>, Peter Gutmann <pgut001@cs.auckland.ac.nz>
Message-ID: <20170327072447.GA2827@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CADPMZDByTiWov0vp2Tk1n9dnnkfwepO+UsAnh3rdsrbem2H=VQ@mail.gmail.com> <1490575901696.39454@cs.auckland.ac.nz> <CADPMZDDNZTznKBJ2-vf4MJFjP0Bx34ALF8JCVBhwv12Pdm=XcA@mail.gmail.com> <CADZyTk=L2mKheNkHQ+jtecspLnR2rGc1BajkTKQ0G3cynxkwow@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CADZyTk=L2mKheNkHQ+jtecspLnR2rGc1BajkTKQ0G3cynxkwow@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/lTzxKCmo_BZg5ol6_gBFibXrsKc>
Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.txt
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Mar 2017 07:24:56 -0000

On Sun, Mar 26, 2017 at 10:50:02PM -0500, Daniel Migault wrote:
> Whether pss variant have to be added is up to the WG to decide. That I
> would be in favor is only one opinion ;-) [1] lists some advantages of PSS
> vs PKCS1v1.5. Note that enabling a given key may be used by two variants
> needs also some thoughts. I will raise the question during the meeting, but
> discussion will be made on the mailing list.

This thing came up in context of TLS 1.3.

The probability PKCS#1v1.5 and PSS signature overlaps depends on key
size and salt size. Where overlap is defined as encoded message that
is valid in both PKCS#1v1.5 and PSS. These depend on hashing algorithm
and number of bits in n, but not precise value of n.

TLS restricts salt length to be the same as hash length. Which makes
overlaps highly unlikely with key sizes >=2048 bits and hash sizes
<=512 bits. The problem being to control ~1000 bits using 512 bits.

As key size decreases or salt size increases, the overlap probability
increases, and eventually overlaps become almost certain, and further
one gets multiple overlaps.

> 
> [1]
> https://www.emc.com/emc-plus/rsa-labs/historical/raising-standard-rsa-signatures-rsa-pss.htm


-Ilari