Re: [TLS] RSA-PSS in TLS 1.3

Nikos Mavrogiannopoulos <nmav@redhat.com> Mon, 07 March 2016 13:42 UTC

Return-Path: <nmav@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 C6C8C1B410A for <tls@ietfa.amsl.com>; Mon, 7 Mar 2016 05:42:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.602
X-Spam-Level:
X-Spam-Status: No, score=-6.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.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 CmEWMQqFy9js for <tls@ietfa.amsl.com>; Mon, 7 Mar 2016 05:42:19 -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 79E731B2F46 for <tls@ietf.org>; Mon, 7 Mar 2016 05:42:19 -0800 (PST)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id CE7FB1E58; Mon, 7 Mar 2016 13:42:18 +0000 (UTC)
Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.105]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u27DgFda017501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Mar 2016 08:42:17 -0500
Message-ID: <1457358135.3117.43.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>, Hanno Böck <hanno@hboeck.de>, "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>, "tls@ietf.org" <tls@ietf.org>
Date: Mon, 07 Mar 2016 14:42:15 +0100
In-Reply-To: <3611ab23e3f948b4bfa0bdd0b348bcc2@XCH-RCD-006.cisco.com>
References: <20160303152945.18296912.40009.55386@ll.mit.edu> <20160303171117.12e627b3@pc1> <1457078973.19296.1.camel@redhat.com> <3611ab23e3f948b4bfa0bdd0b348bcc2@XCH-RCD-006.cisco.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/DZ26-hucmQhWBPW7fDYIsbr4FaA>
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 13:42:20 -0000

On Fri, 2016-03-04 at 13:49 +0000, Scott Fluhrer (sfluhrer) wrote:
> 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

Assuming that we have such algorithms which are practical to manage and
deploy we would first need to enhance existing protocols with them,
including TLS and PKI. Then it is only the (simple) task of
upgrading/replacing every single piece of infrastructure we have today
from certificates to implementations with the new algorithms. 

Unless you can use the quantum computer to complete the above
transition overnight, the quickest way to defend against the presence
of a quantum computer is by allowing larger RSA keys.

regards,
Nikos