Re: [TLS] RSA-PSS in TLS 1.3

"Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> Mon, 07 March 2016 16:34 UTC

Return-Path: <sfluhrer@cisco.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 D5F571B4432 for <tls@ietfa.amsl.com>; Mon, 7 Mar 2016 08:34:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.902
X-Spam-Level:
X-Spam-Status: No, score=-11.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 64zJZBcR850B for <tls@ietfa.amsl.com>; Mon, 7 Mar 2016 08:34:30 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7FE1B4423 for <tls@ietf.org>; Mon, 7 Mar 2016 08:34:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5526; q=dns/txt; s=iport; t=1457368467; x=1458578067; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RH0SNi7VVFtP3EwDpN1/2guMDeakdtB2aAGOhdbn/BY=; b=iVeUCzqBLfLByVowncZaxojESzrASGKYAErtpkQ1JfHzzUpBjXd0OteD dKghmPQND5xNAmL5akrzCdvYeQeZaVnDcfwrFATQ71gnrGA8JBheDKCoo MXxJCSfTixj0m5lmD0KaBIiPkYh0Jn4k7Amz4fLdiReqWbIoSP1oVJwrB E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAgAArd1W/51dJa1cDoMsgT8GujoBD?= =?us-ascii?q?YFphg8CHIENOBQBAQEBAQEBZCeEQQEBAQMBIxFAEQQCAQgRBAEBAQICIwMCAgI?= =?us-ascii?q?wFAEICAEBBAESCIgUCLAHjn8BAQEBAQEBAQEBAQEBAQEBAQEBF3uFHIQ9hCIJg?= =?us-ascii?q?w+BOgWXKgGNZYFqjReFeYhbAR4BAUKCAhqBDTtqiAQ7fgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,552,1449532800"; d="scan'208";a="245701693"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2016 16:34:26 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u27GYQrw020923 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Mar 2016 16:34:26 GMT
Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 7 Mar 2016 10:34:25 -0600
Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Mon, 7 Mar 2016 10:34:25 -0600
From: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>, =?utf-8?B?SGFubm8gQsO2Y2s=?= <hanno@hboeck.de>, "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] RSA-PSS in TLS 1.3
Thread-Index: AdF1YX6hVOviuew0z0qjJ4Wpjso/6gAOBziAACF3k4AAAP03AAChgSqAAAfIBWA=
Date: Mon, 7 Mar 2016 16:34:25 +0000
Message-ID: <8063d9927c134546ad3f2226b960b516@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> <1457358135.3117.43.camel@redhat.com>
In-Reply-To: <1457358135.3117.43.camel@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.98.2.61]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/BMg93XKuMa1YehKqCNPG5Lwjszo>
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 16:34:32 -0000

> -----Original Message-----
> From: Nikos Mavrogiannopoulos [mailto:nmav@redhat.com]
> Sent: Monday, March 07, 2016 8:42 AM
> To: Scott Fluhrer (sfluhrer); Hanno Böck; Blumenthal, Uri - 0553 - MITLL;
> tls@ietf.org
> Subject: Re: [TLS] RSA-PSS in TLS 1.3
> 
> 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.

There are two threats that a Quantum Computer may bring:

- Someone (who might not have a QC now) recording the encrypting traffic, and then (when they do have a QC) decrypting the traffic
- Someone with a QC forging our authentication (certificates),and acting either as an imposter, or as a man-in-the-middle.

The second attack isn't feasible until someone actually has a QC at the time of the attack; for the first attack, that's a threat until the data being protected is no longer of any interest - depending on what that data is, that may be decades.

To defend against the first attack, we don't need to update the entire infrastructure.  Instead, all we need to do is update the client and the server to use a Quantum-Resistant ciphersuite (I'd argue that a QR named group would actually be preferable, however that's an argument for another time).  We know how to do a gradual rollout of this.

To defend against the second attack, yes, that would require changes to PKI, which this WG isn't in charge of.  However, these attacks become a threat later.


So, the points I want to make are:

- Defenses against the first type of attack (passive evesdropping by someone who will build a QC sometime in the future) are something that this WG should address; even if the PKI people don't have an answer, we would at least be secure from someone recording the traffic and decrypting it later
- Large size RSA keys (actually, DH groups; TLS 1.3 doesn't use RSA for key transport) don't necessarily add any protection from a QC (depending on how fast practical QC's ramp up).

> 
> 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.

Actually, that brings up a point; if we are worried about some old, unupdatable servers, how are we going to ever upgrade our authentication infrastructure?  A lot of those are built on cryptolibraries that cannot handle 16K RSA keys any more than they can handle Hash Based or BLISS certificates.  However, that's an argument for another time (and probably not by this WG)