> -----Original Message-----
> From: Nikos Mavrogiannopoulos [mailto:[email protected]]
> Sent: Monday, March 07, 2016 8:42 AM
> To: Scott Fluhrer (sfluhrer); Hanno Böck; Blumenthal, Uri - 0553 - MITLL;
> [email protected]
> 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)
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls

Reply via email to