Re: [TLS] RSA-PSS in TLS 1.3
Hubert Kario <hkario@redhat.com> Mon, 07 March 2016 11:42 UTC
Return-Path: <hkario@redhat.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 BD2481B3EA5 for <tls@ietfa.amsl.com>; Mon, 7 Mar 2016 03:42:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_BACK=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_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 s9m-qwpNw5ny for <tls@ietfa.amsl.com>; Mon, 7 Mar 2016 03:42:49 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9DF1B3F63 for <tls@ietf.org>; Mon, 7 Mar 2016 03:42:48 -0800 (PST)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id F2A2672097; Mon, 7 Mar 2016 11:42:47 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-120.brq.redhat.com [10.34.0.120]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u27Bgjw4015294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Mar 2016 06:42:46 -0500
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Mon, 07 Mar 2016 12:42:39 +0100
Message-ID: <5209728.bPpGhxeIz8@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.10 (Linux/4.3.6-201.fc22.x86_64; KDE/4.14.17; x86_64; ; )
In-Reply-To: <3611ab23e3f948b4bfa0bdd0b348bcc2@XCH-RCD-006.cisco.com>
References: <20160303152945.18296912.40009.55386@ll.mit.edu> <1457078973.19296.1.camel@redhat.com> <3611ab23e3f948b4bfa0bdd0b348bcc2@XCH-RCD-006.cisco.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1715409.DF22txT6Jk"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 07 Mar 2016 11:42:48 +0000 (UTC)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/CDbceqPFYpUDZWtbrKwjEjN4M1E>
Subject: Re: [TLS] RSA-PSS in TLS 1.3
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: <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: Mon, 07 Mar 2016 11:42:50 -0000
On Friday 04 March 2016 13:49:11 Scott Fluhrer wrote: > > -----Original Message----- > > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Nikos > > Mavrogiannopoulos > > Sent: Friday, March 04, 2016 3:10 AM > > To: Hanno Böck; Blumenthal, Uri - 0553 - MITLL; tls@ietf.org > > Subject: Re: [TLS] RSA-PSS in TLS 1.3 > > > > On Thu, 2016-03-03 at 17:11 +0100, Hanno Böck wrote: > > > > > It may be worth asking the authors what's their opinion of FDH vs > > > > > > > PSS > > > > in view of the state of the art *today*. > > > > > > You may do that, but I doubt that changes much. > > > > > > > > > > > > I think FDH really is not an option at all here. It may very well > > > be > > > that there are better ways to do RSA-padding, but I don't think > > > that > > > this is viable for TLS 1.3 (and I don't think FDH is better). > > > PSS has an RFC (3447) and has been thoroughly analyzed by > > > research. I think there has been far less analyzing effort > > > towards FDH (or any other construction) and it is not in any way > > > specified in a standards document. If one would want to use FDH > > > or anything else one would imho first have to go through some > > > standardization process (which could be CFRG or NIST or someone > > > else) and call for a thorough analysis of it by the cryptographic > > > community. Which would take at least a couple of years. > > > > > > > > > > > > Given that there probably is no long term future for RSA anyway > > > (people want ECC and postquantum is ahead) I doubt anything else > > > than the primitives we already have in standards will ever be > > > viable.> > > > > On the contrary. If we have a future with quantum computers > > available, the only thing that we have now and would work is RSA > > with larger keys, not ECC. > > RSA isn't *that* much more secure against a Quantum Computer than ECC. > It would appear to take a larger Quantum Computer to break RSA than > it would to break ECC (for reasonable moduli/curve sizes), however > not that much more. It is possible that, at one stage, we'll be able > to build a QC that's just large enough to break EC curves, but not > larger RSA keys - however, we would be likely to be able to scale up > our QC to be a bit larger; possibly in a few months, quite likely in > a year or two. Hence, moving back to RSA would appear likely to buy > us only a short window... > I agree with Hanno; if we're interested in defending against a Quantum > Computer, post Quantum algorithms are the way to go except that using RSA keys nearly an order of magnitude larger than the biggest ECC curve that's widely supported (secp384) is the current recommended minimum by ENISA and long term minimum by NIST (3072). Using keys 5 times larger still is not impossible, so while it may not buy us extra 20 years after ECC is broken, 10 years is not impossible and 5 is almost certain (if Moore's law holds for quantum computers). It's not much, but it may be enough to make a difference. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
- Re: [TLS] RSA-PSS in TLS 1.3 Andrey Jivsov
- Re: [TLS] RSA-PSS in TLS 1.3 Russ Housley
- Re: [TLS] RSA-PSS in TLS 1.3 Joseph Salowey
- Re: [TLS] RSA-PSS in TLS 1.3 Yoav Nir
- Re: [TLS] RSA-PSS in TLS 1.3 Hanno Böck
- [TLS] RSA-PSS in TLS 1.3 Joseph Salowey
- Re: [TLS] RSA-PSS in TLS 1.3 Viktor Dukhovni
- Re: [TLS] RSA-PSS in TLS 1.3 Benjamin Beurdouche
- Re: [TLS] RSA-PSS in TLS 1.3 Yoav Nir
- Re: [TLS] RSA-PSS in TLS 1.3 Brian Smith
- Re: [TLS] RSA-PSS in TLS 1.3 Andrey Jivsov
- Re: [TLS] RSA-PSS in TLS 1.3 Salz, Rich
- Re: [TLS] RSA-PSS in TLS 1.3 Andrey Jivsov
- Re: [TLS] RSA-PSS in TLS 1.3 Dave Garrett
- Re: [TLS] RSA-PSS in TLS 1.3 Hanno Böck
- Re: [TLS] RSA-PSS in TLS 1.3 Andrey Jivsov
- Re: [TLS] RSA-PSS in TLS 1.3 Martin Thomson
- Re: [TLS] RSA-PSS in TLS 1.3 Viktor Dukhovni
- Re: [TLS] RSA-PSS in TLS 1.3 Viktor Dukhovni
- Re: [TLS] RSA-PSS in TLS 1.3 Martin Thomson
- Re: [TLS] RSA-PSS in TLS 1.3 Nikos Mavrogiannopoulos
- Re: [TLS] RSA-PSS in TLS 1.3 Yoav Nir
- Re: [TLS] RSA-PSS in TLS 1.3 Yoav Nir
- Re: [TLS] RSA-PSS in TLS 1.3 Alyssa Rowan
- Re: [TLS] RSA-PSS in TLS 1.3 Watson Ladd
- Re: [TLS] RSA-PSS in TLS 1.3 Viktor Dukhovni
- Re: [TLS] RSA-PSS in TLS 1.3 Yoav Nir
- Re: [TLS] RSA-PSS in TLS 1.3 Hanno Böck
- Re: [TLS] RSA-PSS in TLS 1.3 Martin Thomson
- Re: [TLS] RSA-PSS in TLS 1.3 Andrey Jivsov
- Re: [TLS] RSA-PSS in TLS 1.3 Yoav Nir
- Re: [TLS] RSA-PSS in TLS 1.3 Viktor Dukhovni
- Re: [TLS] RSA-PSS in TLS 1.3 Rob Stradling
- Re: [TLS] RSA-PSS in TLS 1.3 Rob Stradling
- Re: [TLS] RSA-PSS in TLS 1.3 Yoav Nir
- Re: [TLS] RSA-PSS in TLS 1.3 Eric Rescorla
- Re: [TLS] RSA-PSS in TLS 1.3 Yoav Nir
- Re: [TLS] RSA-PSS in TLS 1.3 Dave Garrett
- Re: [TLS] RSA-PSS in TLS 1.3 Dang, Quynh (Fed)
- Re: [TLS] RSA-PSS in TLS 1.3 Hanno Böck
- Re: [TLS] RSA-PSS in TLS 1.3 Dang, Quynh (Fed)
- Re: [TLS] RSA-PSS in TLS 1.3 Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] RSA-PSS in TLS 1.3 Hanno Böck
- Re: [TLS] RSA-PSS in TLS 1.3 Dang, Quynh (Fed)
- Re: [TLS] RSA-PSS in TLS 1.3 Nikos Mavrogiannopoulos
- Re: [TLS] RSA-PSS in TLS 1.3 Martin Rex
- Re: [TLS] RSA-PSS in TLS 1.3 Scott Fluhrer (sfluhrer)
- Re: [TLS] RSA-PSS in TLS 1.3 Hanno Böck
- Re: [TLS] RSA-PSS in TLS 1.3 Martin Rex
- Re: [TLS] RSA-PSS in TLS 1.3 Fedor Brunner
- Re: [TLS] RSA-PSS in TLS 1.3 Martin Rex
- Re: [TLS] RSA-PSS in TLS 1.3 Hubert Kario
- Re: [TLS] RSA-PSS in TLS 1.3 Nikos Mavrogiannopoulos
- Re: [TLS] RSA-PSS in TLS 1.3 Hannes Mehnert
- Re: [TLS] RSA-PSS in TLS 1.3 Scott Fluhrer (sfluhrer)
- Re: [TLS] RSA-PSS in TLS 1.3 Ilari Liusvaara
- Re: [TLS] RSA-PSS in TLS 1.3 Scott Fluhrer (sfluhrer)
- Re: [TLS] RSA-PSS in TLS 1.3 Scott Fluhrer (sfluhrer)
- Re: [TLS] RSA-PSS in TLS 1.3 Hubert Kario
- Re: [TLS] RSA-PSS in TLS 1.3 Tony Arcieri
- [TLS] (TLS1.3 - algorithm agility support is enou… Rene Struik
- Re: [TLS] (TLS1.3 - algorithm agility support is … Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] (TLS1.3 - algorithm agility support is … Scott Fluhrer (sfluhrer)
- Re: [TLS] RSA-PSS in TLS 1.3 Scott Fluhrer (sfluhrer)
- Re: [TLS] RSA-PSS in TLS 1.3 Hubert Kario
- Re: [TLS] RSA-PSS in TLS 1.3 Viktor Dukhovni
- Re: [TLS] RSA-PSS in TLS 1.3 Hubert Kario
- Re: [TLS] RSA-PSS in TLS 1.3 Tony Arcieri