Re: [TLS] RSA-PSS in TLS 1.3

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

> -----Original Message-----
> From: Nikos Mavrogiannopoulos [mailto:[e-mail]]
> Sent: Monday, March 07, 2016 8:42 AM
> To: Scott Fluhrer (sfluhrer); Hanno Böck; Blumenthal, Uri - 0553 - MITLL;
> [e-mail]
> 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)