Re: [TLS] RSA-PSS in TLS 1.3

[Andrey Jivsov]

On 07/06/2016 10:23 AM, Joseph Salowey wrote:
> I don't think we ever call consensus on this topic.  It looks like there
> is rough consensus to move forward with RSA-PSS as the MUST implement
> algorithm for certificate verify in TLS 1.3 and not allow PKCS-1.5.  
> During the discussion it also seemed that it is realistic that we may
> want to add additional types in the future.  We may want better
> separation of signature types of certificates and certificate verify.  
> 
> Cheers,
> 
> J

Was it really the consensus that the group didn't want to allow PKCS-1.5
negotiated for handshake signatures (for certificate verifies)?

TLS 1.3 currently allows this agility for other signatures: the
signatures in X.509 certificates.

Nobody has objections to a MUST implement and MUST prefer RSA-PSS in TLS
1.3.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Joseph Salowey]

I don't think we ever call consensus on this topic.  It looks like there is
rough consensus to move forward with RSA-PSS as the MUST implement
algorithm for certificate verify in TLS 1.3 and not allow PKCS-1.5.
During the discussion it also seemed that it is realistic that we may want
to add additional types in the future.  We may want better separation of
signature types of certificates and certificate verify.

Cheers,

J

On Wed, Mar 9, 2016 at 2:05 AM, Hubert Kario  wrote:

> On Tuesday 08 March 2016 18:41:32 Viktor Dukhovni wrote:
> > On Tue, Mar 08, 2016 at 07:24:37PM +0100, Hubert Kario wrote:
> > > No, I said that we have no reason to believe that quantum computers
> > > won't follow exponential increase in number of qbits they can
> > > handle,
> > > with the highest increase not exceeding doubling every year, but
> > > more
> > > likely doubling every two years (as every other technological
> > > development did till now).
> >
> > There's reason to be skeptical of such analogies.  Moore's law was
> > neither a theorem nor a law of nature.  It was an observation about
> > progress in feature-size shrink of silicon transistors.  It is far
> > from clear that evolution of silicon fabrication is a relevant model.
>
> That's why I'm not saying that it will be exactly like Moore's law.
>
> My point is, that processes which have super-exponential growth are the
> exception, not the rule (if they exist at all). And you would be hard
> pressed to find any process in history that experienced exponential
> growth over a long time span and be at the same time vastly faster than
> the Moore's law.
> --
> 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
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Hubert Kario]

On Tuesday 08 March 2016 18:41:32 Viktor Dukhovni wrote:
> On Tue, Mar 08, 2016 at 07:24:37PM +0100, Hubert Kario wrote:
> > No, I said that we have no reason to believe that quantum computers
> > won't follow exponential increase in number of qbits they can
> > handle,
> > with the highest increase not exceeding doubling every year, but
> > more
> > likely doubling every two years (as every other technological
> > development did till now).
> 
> There's reason to be skeptical of such analogies.  Moore's law was
> neither a theorem nor a law of nature.  It was an observation about
> progress in feature-size shrink of silicon transistors.  It is far
> from clear that evolution of silicon fabrication is a relevant model.

That's why I'm not saying that it will be exactly like Moore's law.

My point is, that processes which have super-exponential growth are the 
exception, not the rule (if they exist at all). And you would be hard 
pressed to find any process in history that experienced exponential 
growth over a long time span and be at the same time vastly faster than 
the Moore's law.
-- 
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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Viktor Dukhovni]

On Tue, Mar 08, 2016 at 07:24:37PM +0100, Hubert Kario wrote:

> No, I said that we have no reason to believe that quantum computers 
> won't follow exponential increase in number of qbits they can handle, 
> with the highest increase not exceeding doubling every year, but more 
> likely doubling every two years (as every other technological 
> development did till now).

There's reason to be skeptical of such analogies.  Moore's law was
neither a theorem nor a law of nature.  It was an observation about
progress in feature-size shrink of silicon transistors.  It is far
from clear that evolution of silicon fabrication is a relevant model.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Hubert Kario]

On Tuesday 08 March 2016 16:53:18 Scott Fluhrer wrote:
> > -Original Message-
> > From: Hubert Kario [mailto:hka...@redhat.com]
> > Sent: Monday, March 07, 2016 12:18 PM
> > To: Scott Fluhrer (sfluhrer)
> > Cc: tls@ietf.org; Nikos Mavrogiannopoulos; Hanno Böck; Blumenthal,
> > Uri - 0553 - MITLL
> > Subject: Re: [TLS] RSA-PSS in TLS 1.3
> > 
> > On Monday 07 March 2016 15:23:17 Scott Fluhrer wrote:
> > 
> > 
> > > In 2001, a Quantum Computer factored a 4 bit number.  In 2014,
> > > the
> > > factorization of a 16 bit number was announced (however, the
> > > factorization used a special relationship between the factors, so
> > > I
> > > don’t think it counts as a general factorization, but let's
> > > ignore
> > > that for now).  That's not too far off from a Moore's law type
> > > expansion.  If this rate continues, well see the first 1024 bit
> > > factorization circa the year 3100 AD (aka CE).
> > 
> > 
> > GIGO, you're extrapolating from two data points when we have no idea
> > how fast or how slow will be the progress in general
> 
> 
> Actually, that sort of logic is what you're using.  You have no idea
> how fast or slow will the progress be in general, however you assure
> us that it'll be take significantly longer to create a Quantum
> Computer that can break large key RSA than it would be to break ECC.

No, I said that we have no reason to believe that quantum computers 
won't follow exponential increase in number of qbits they can handle, 
with the highest increase not exceeding doubling every year, but more 
likely doubling every two years (as every other technological 
development did till now).

I'd really like to hear an expert that will say that building a 1,000 
qbit QC will be just as easy as building a 100,000 qbit one.

> If you don't believe the oversimplified logic I showed above, you must
> assume that, at some point in the future, that Quantum Computers must
> increase much more rapidly than a simple Moore's law prediction
> (based on simple extrapolation from what we have now).  However, you
> assume that this rapid expansion will stop at a point insufficient to
> break large key RSA.

I said that this exponential growth in quantum computers most likely 
*won't* provide us 20 years of RSA/DH unbreakability after ECC falls. 
How is that saying that RSA will not be broken by quantum computers?

> > 
> > and I meant Moore's 18-24 months per double, not the idea of
> > exponential growth in general; in other words P-256 succumbing to
> > quantum computers 4 to 8 years before 1024 bit RSA
> 
> 
> As you are making assertions on the likely progress in building
> Quantum Computers, I have to ask: what expertise do you have in the
> design and construction of Quantum Computers?  How up to date are you
> on the theory?  Are you familiar with Toffoli gates or Clifford
> gates?  How about magic state factories [real name]?
 
> I'm not an expert in this field either - however, I have talked to
> experts; the opinions I've heard is that a realistic computer that
> can break RSA is perhaps 10-15 years off (estimates differ between
> experts); once it's been built, scaling it up isn't likely to be much
> of an issue (largely because we already know how to etch quite large
> construction onto Silicon).  In essence, the problem isn't the actual
> construction process, but knowing what to build.

RSA of what size? and what about ECC?

Using currently known algorithms, to break 256 bit ECC you need 384 qbit 
quantum computer

To break 15360 bit RSA or DH you need 23040 qbit quantum computer.

Assuming explosive growth of quantum computer sizes (doubling every 
year), RSA of that size will be broken 6 years after the above ECC.

Does that mean that ECC will fall in 4 to 6 years?

> Might they be wrong?  Might they be overoptimistic about their
> technology?  Might there be a practical bump in the road that they
> don't foresee yet?  Perhaps; however it wouldn't appear prudent to
> assume that.
 
> And, I would argue that 10-15 years isn't that far off, since we need
> to worry about someone storing the encrypted data now, and decrypting
> them later.
 
Quantum Computers are all or nothing, you can't use a 256 qbit QC to 
break 512 bit RSA, you need a 768 qbit QC to break it. Any smaller one 
won't be more effective than classical computer.

> The bottom line: am I saying that you shouldn't start supporting large
> key RSA as a short term solution, in the hopes that it might fend off
> a Quantum Computer for a bit?  No, as that's not likely to be
> harmful, go ahead and knock yourself out.  However, I am saying that
> it would be foolish to pretend that is anything but a short

Re: [TLS] RSA-PSS in TLS 1.3

[Scott Fluhrer (sfluhrer)]

> -Original Message-
> From: Hubert Kario [mailto:hka...@redhat.com]
> Sent: Monday, March 07, 2016 12:18 PM
> To: Scott Fluhrer (sfluhrer)
> Cc: tls@ietf.org; Nikos Mavrogiannopoulos; Hanno Böck; Blumenthal, Uri -
> 0553 - MITLL
> Subject: Re: [TLS] RSA-PSS in TLS 1.3
> 
> On Monday 07 March 2016 15:23:17 Scott Fluhrer wrote:
> > > -Original Message-
> > > From: Hubert Kario [mailto:hka...@redhat.com]
> > > Sent: Monday, March 07, 2016 6:43 AM
> > > To: tls@ietf.org
> > > Cc: Scott Fluhrer (sfluhrer); Nikos Mavrogiannopoulos; Hanno Böck;
> > > Blumenthal, Uri - 0553 - MITLL
> > > Subject: Re: [TLS] RSA-PSS in TLS 1.3
> > >
> > > On Friday 04 March 2016 13:49:11 Scott Fluhrer wrote:
> > >
> > > > 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.
> >
> >
> > If we believe that growth in Moore's law will be accurate for Quantum
> > Computers, then no one has to worry about Quantum Computers for the
> > next millennia.
> 
> > In 2001, a Quantum Computer factored a 4 bit number.  In 2014, the
> > factorization of a 16 bit number was announced (however, the
> > factorization used a special relationship between the factors, so I
> > don’t think it counts as a general factorization, but let's ignore
> > that for now).  That's not too far off from a Moore's law type
> > expansion.  If this rate continues, well see the first 1024 bit
> > factorization circa the year 3100 AD (aka CE).
> 
> GIGO, you're extrapolating from two data points when we have no idea how
> fast or how slow will be the progress in general

Actually, that sort of logic is what you're using.  You have no idea how fast 
or slow will the progress be in general, however you assure us that it'll be 
take significantly longer to create a Quantum Computer that can break large key 
RSA than it would be to break ECC.

If you don't believe the oversimplified logic I showed above, you must assume 
that, at some point in the future, that Quantum Computers must increase much 
more rapidly than a simple Moore's law prediction (based on simple 
extrapolation from what we have now).  However, you assume that this rapid 
expansion will stop at a point insufficient to break large key RSA.

> 
> and I meant Moore's 18-24 months per double, not the idea of exponential
> growth in general; in other words P-256 succumbing to quantum computers
> 4 to 8 years before 1024 bit RSA

As you are making assertions on the likely progress in building Quantum 
Computers, I have to ask: what expertise do you have in the design and 
construction of Quantum Computers?  How up to date are you on the theory?  Are 
you familiar with Toffoli gates or Clifford gates?  How about magic state 
factories [real name]?

I'm not an expert in this field either - however, I have talked to experts; the 
opinions I've heard is that a realistic computer that can break RSA is perhaps 
10-15 years off (estimates differ between experts); once it's been built, 
scaling it up isn't likely to be much of an issue (largely because we already 
know how to etch quite large construction onto Silicon).  In essence, the 
problem isn't the actual construction process, but knowing what to build.

Might they be wrong?  Might they be overoptimistic about their technology?  
Might there be a practical bump in the road that they don't foresee yet?  
Perhaps; however it wouldn't appear prudent to assume that.

And, I would argue that 10-15 years isn't that far off, since we need to worry 
about someone storing the encrypted data now, and decrypting them later.


The bottom line: am I saying that you shouldn't start supporting large key RSA 
as a short term solution, in the hopes that it might fend off a Quantum 
Computer for a bit?  No, as that's not likely to be harmful, go ahead and knock 
yourself out.  However, I am saying that it would be foolish to pretend that is 
anything but a shortterm patch at best; it might end up providing no additional 
protection.  If we're interested in a longer term solution, we would need to 
eventually go with real postquantum cryptography (and I would argue that 
'eventually' isn't that far in the future).

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Hubert Kario]

On Monday 07 March 2016 15:23:17 Scott Fluhrer wrote:
> > -Original Message-
> > From: Hubert Kario [mailto:hka...@redhat.com]
> > Sent: Monday, March 07, 2016 6:43 AM
> > To: tls@ietf.org
> > Cc: Scott Fluhrer (sfluhrer); Nikos Mavrogiannopoulos; Hanno Böck;
> > Blumenthal, Uri - 0553 - MITLL
> > Subject: Re: [TLS] RSA-PSS in TLS 1.3
> > 
> > On Friday 04 March 2016 13:49:11 Scott Fluhrer wrote:
> > 
> > > > -Original Message-
> > > > From: TLS [mailto:tls-boun...@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 alm

Re: [TLS] RSA-PSS in TLS 1.3

[Scott Fluhrer (sfluhrer)]

> -Original Message-
> From: Nikos Mavrogiannopoulos [mailto:n...@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 +, 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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Scott Fluhrer (sfluhrer)]

> -Original Message-
> From: Hubert Kario [mailto:hka...@redhat.com]
> Sent: Monday, March 07, 2016 6:43 AM
> To: tls@ietf.org
> Cc: Scott Fluhrer (sfluhrer); Nikos Mavrogiannopoulos; Hanno Böck;
> Blumenthal, Uri - 0553 - MITLL
> Subject: Re: [TLS] RSA-PSS in TLS 1.3
> 
> On Friday 04 March 2016 13:49:11 Scott Fluhrer wrote:
> > > -Original Message-
> > > From: TLS [mailto:tls-boun...@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.

If we believe that growth in Moore's law will be accurate for Quantum 
Computers, then no one has to worry about Quantum Computers for the next 
millennia.

In 2001, a Quantum Computer factored a 4 bit number.  In 2014, the 
factorization of a 16 bit number was announced (however, the factorization used 
a special relationship between the factors, so I don’t think it counts as a 
general factorization, but let's ignore that for now).  That's not too far off 
from a Moore's law type expansion.  If this rate continues, well see the first 
1024 bit factorization circa the year 3100 AD (aka CE).

However, right now one of the chief problems in building a Quantum Computer is 
error correction; catching when decoherence has occurred, and fixing it before 
it spoils the entire operation.  Once they have that solved, practical Quantum 
Computers may get much bigger very fast.

Might they, after the initial explosive growth (to 1000 qbits or 1,000,000 
qbits, I don't think anyone knows where that point would be), might it continue 
to grow in a Moore's law fashion?  It might; however we're not sure.  Using RSA 
keys which are 5 times larger might not buy us any time at all...

> 
> --
> 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Hannes Mehnert]

On 01/03/2016 11:32, Yoav Nir wrote:
>> On 1 Mar 2016, at 6:56 AM, Martin Thomson  wrote:
>>
>> On 1 March 2016 at 04:32, Joseph Salowey  wrote:
>>> We make RSA-PSS mandatory to implement (MUST implement instead of MUST
>>> offer).   Clients can advertise support for PKCS-1.5 for backwards
>>> compatibility in the transition period.
>>
>>> From my perspective, this is fine.  I would like to say that we won't
>> ever support PKCS#1.5 for TLS 1.3, but I think that I would rather
>> have users on 1.3 with PKCS#1.5 than have them stuck on 1.2.
>>
>> It seems like others are taking the position that we should say "MUST
>> NOT use PKCS#1.5”.  
> 
> I’d go even further. I’d remove the rsapss(4) value from SignatureAlgorithm, 
> leaving just rsa(1), and say that in TLS 1.3 an RSA signature is PSS just as 
> it was PKCS#1.5 in TLS 1.2.

I strongly agree to Yoav's proposal!  No need to have both RSA(-PKCS)
and RSA-PSS numbers in SignatureAlgorithms.


hannes

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Martin Rex]

Fedor Brunner wrote:
> 
> Please see the paper "Another Look at ``Provable Security''" from Neal
> Koblitz and Alfred Menezes.
> 
> https://eprint.iacr.org/2004/152
> 
> Section 7: Conclusion
> 
> "There is no need for the PSS or Katz-Wang versions of RSA;
> one might as well use just the basic ?hash and exponentiate? signature
> scheme (with a full-domain hash function)."


Thanks a million for adding some clue to this discussion!

-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Martin Rex]

Hanno Böck wrote:
> m...@sap.com (Martin Rex) wrote:
>>
>> The *huge* advantage of PKCS#1 v1.5 signatures over RSA-PSS and ECDSA
>> signatures is that one can clearly distinguish "wrong public key"
>> from "signature does not fit plaintext" errors, and loosing this
>> capability makes certain kinds of programming goofs (plus a few
>> admin configuration goofs) much harder to distinguish from
>> data corruption during transfer.
> 
> Actually I see this as a disadvantage. Separating different error
> states has been the source of a whole number of vulnerabilities. The
> original Bleichenbacher attack (and all its variants including drown)
> is based on separating different errors, the Vaudenay attack is.

I'm sorry, but this is clueless.
Signature verification is a PUBLIC KEY operation.
You're not creating an oracle with a public key operation.

The examples you cite are about secret key and private key operations
which create oracles.  That isn't even in the same universe.

-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Hanno Böck]

On Fri, 4 Mar 2016 14:45:13 +0100 (CET)
m...@sap.com (Martin Rex) wrote:

> What should have adopted for TLSv1.2 already, however, is the less
> forgiving PKCS#1 v1.5 signature check, that re-creates the encoding
> and then compares the recreated inner encoding with the RSA-decrypted
> encoding only.  Get rid of the de-padding and get rid of the ASN.1
> decoding of the contents.

The Problem with this is that you're relying on the implementor to get
it right. Sure, you're giving them a receip how they could implement
the check to be correct, but you have no way of checking whether they
actually follow that receip.
Given all past experiences I'd bet you can write whatever you want in
your new standards document, no implementor will replace their
(seemingly working, but insecure) PKCS #1 1.5 implementation as long
as it works, just because you say they have to do it in a
different way than they did in the past.

> The *huge* advantage of PKCS#1 v1.5 signatures over RSA-PSS and ECDSA
> signatures is that one can clearly distinguish "wrong public key"
> from "signature does not fit plaintext" errors, and loosing this
> capability makes certain kinds of programming goofs (plus a few
> admin configuration goofs) much harder to distinguish from
> data corruption during transfer.

Actually I see this as a disadvantage. Separating different error
states has been the source of a whole number of vulnerabilities. The
original Bleichenbacher attack (and all its variants including drown)
is based on separating different errors, the Vaudenay attack is.


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpYHTQr5FQIB.pgp
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Martin Rex]

Hanno Böck wrote:
> Joseph Salowey  wrote:
>> 
>> We make RSA-PSS mandatory to implement (MUST implement instead of MUST
>> offer).   Clients can advertise support for PKCS-1.5 for backwards
>> compatibility in the transition period.
>> Please respond on the list on whether you think this is a reasonable
>> way forward or not.
> 
> I recently already saw the message here asking for PKCS #1 1.5
> compatibilty and was quite angry about it, but as there wasn't much
> discussion I thought this issue would go away. It seems it did not.
> 
> RSA-PSS was specified as RFC 3447 in 2003. That was 13 years ago.

RSA-PSS signatures are crap, and they're pretty close to useless.

What should have adopted for TLSv1.2 already, however, is the less
forgiving PKCS#1 v1.5 signature check, that re-creates the encoding
and then compares the recreated inner encoding with the RSA-decrypted
encoding only.  Get rid of the de-padding and get rid of the ASN.1
decoding of the contents.  This is also the recommended fashion
for PKCS#1 v1.5 signature verification in rfc3447.


The *huge* advantage of PKCS#1 v1.5 signatures over RSA-PSS and ECDSA
signatures is that one can clearly distinguish "wrong public key"
from "signature does not fit plaintext" errors, and loosing this
capability makes certain kinds of programming goofs (plus a few
admin configuration goofs) much harder to distinguish from
data corruption during transfer.  XMLdsig and XML canonicalization
is another source of endless fun, where being able to distinguish
these causes for signature verification failure facilitates
troubleshooting.


Signature verification itself is a public key operation, so RSA-PSS
is a wholly different beast than RSA-OAEP.


-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Dang, Quynh (Fed)]

PSS+SHAKE128/512+SHAKE128 or PSS+SHAKE256/512+SHAKE256 (as SHAKEs being used as 
MGF) would be more efficient options. NIST is working on a formal specification 
for the SHAKEs being used as fixed output-length hash functions such as 
SHAKE128/256, SHAKE128/512 and SHAKE256/512. 

Prepending a random salt of 512-bit in length (fixed length of 512 bits) to the 
message should work and this is very simple and efficient.

Quynh. 




From: TLS <tls-boun...@ietf.org> on behalf of Hanno Böck <ha...@hboeck.de>
Sent: Thursday, March 3, 2016 11:11 AM
To: Blumenthal, Uri - 0553 - MITLL; tls@ietf.org
Subject: Re: [TLS] RSA-PSS in TLS 1.3

On Thu, 3 Mar 2016 15:29:37 +
"Blumenthal, Uri - 0553 - MITLL" <u...@ll.mit.edu> wrote:

> Also, wasn't PSS ‎developed before SHA3 and SHAKE were known, let
> alone available?

Yeah, more than 10 years before.
It's more the other way found: PSS and other constructions showed the
need for hash functions with a defined output length. SHAKE is such a
function. PSS uses a construction called MGF1, which essentially takes
an existing fixed-output-length hash, combines that with a counter and
produces some construction. SHAKE deprecates the need for such a
workaround.

So instead of using PSS+SHA256+MGF1-with-SHA256 you could say you use
PSS+SHA-3-256+SHAKE256. I don't think this changes a whole lot in
regards to security (as long as we assume both sha256 and sha-3-256 are
very secure algorithms).

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


--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Hanno Böck]

On Thu, 3 Mar 2016 15:29:37 +
"Blumenthal, Uri - 0553 - MITLL"  wrote:

> Also, wasn't PSS ‎developed before SHA3 and SHAKE were known, let
> alone available? 

Yeah, more than 10 years before.
It's more the other way found: PSS and other constructions showed the
need for hash functions with a defined output length. SHAKE is such a
function. PSS uses a construction called MGF1, which essentially takes
an existing fixed-output-length hash, combines that with a counter and
produces some construction. SHAKE deprecates the need for such a
workaround.

So instead of using PSS+SHA256+MGF1-with-SHA256 you could say you use
PSS+SHA-3-256+SHAKE256. I don't think this changes a whole lot in
regards to security (as long as we assume both sha256 and sha-3-256 are
very secure algorithms).

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


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpnn2C2wYISN.pgp
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Blumenthal, Uri - 0553 - MITLL]

Also, wasn't PSS ‎developed before SHA3 and SHAKE were known, let alone 
available? 

It may be worth asking the authors what's their opinion of FDH vs PSS in view 
of the state of the art *today*.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Dang, Quynh (Fed)
Sent: Thursday, March 3, 2016 09:21
To: Hanno Böck; tls@ietf.org
Subject: Re: [TLS] RSA-PSS in TLS 1.3

Hi Hanno,

I think the PSS uses a random salt to get the hashing probabilistic.

A customized version of a SHAKE can/may take a domain-separation string or/and 
a random salt.

Quynh. 


From: TLS <tls-boun...@ietf.org> on behalf of Hanno Böck <ha...@hboeck.de>
Sent: Thursday, March 3, 2016 8:49 AM
To: tls@ietf.org
Subject: Re: [TLS] RSA-PSS in TLS 1.3

On Thu, 3 Mar 2016 13:35:46 +
"Dang, Quynh (Fed)" <quynh.d...@nist.gov> wrote:

> Why don't we use an even more elegant RSA signature called "
> full-domain hash RSA signature" ?

Full Domain Hashing was originally developed by Rogaway and Bellare and
then later dismissed because they found that they could do better. Then
they developed PSS.

See
http://web.cs.ucdavis.edu/~rogaway/papers/exact.pdf

So in essence FDH is a predecessor of PSS and the authors of both
schemes came to the conclusion that PSS is the superior scheme.


> As you know, a SHAKE (as a variable output-length hash function)
> naturally produces a hash value which fits any given modulus size.
> Therefore, no paddings are needed which avoids any potential issues
> with the paddings and the signature algorithm would be very simple.

You could also use SHAKE in PSS to replace MGF1. This is probably
desirable if you intent to use PSS with SHA-3.

PSS doesn't really have any padding in the traditional sense. That is,
all the padding is somehow either hashed or xored with a hashed value.
I don't think any of the padding-related issues apply in any way to
PSS, if you disagree please explain.

(shameless plug: I wrote my thesis about PSS, in case anyone wants to
read it: https://rsapss.hboeck.de/ - it's been a while, don't be too
hard on me if I made mistakes)


--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Dang, Quynh (Fed)]

Hi Hanno,

I think the PSS uses a random salt to get the hashing probabilistic.

A customized version of a SHAKE can/may take a domain-separation string or/and 
a random salt.

Quynh. 


From: TLS <tls-boun...@ietf.org> on behalf of Hanno Böck <ha...@hboeck.de>
Sent: Thursday, March 3, 2016 8:49 AM
To: tls@ietf.org
Subject: Re: [TLS] RSA-PSS in TLS 1.3

On Thu, 3 Mar 2016 13:35:46 +
"Dang, Quynh (Fed)" <quynh.d...@nist.gov> wrote:

> Why don't we use an even more elegant RSA signature called "
> full-domain hash RSA signature" ?

Full Domain Hashing was originally developed by Rogaway and Bellare and
then later dismissed because they found that they could do better. Then
they developed PSS.

See
http://web.cs.ucdavis.edu/~rogaway/papers/exact.pdf

So in essence FDH is a predecessor of PSS and the authors of both
schemes came to the conclusion that PSS is the superior scheme.


> As you know, a SHAKE (as a variable output-length hash function)
> naturally produces a hash value which fits any given modulus size.
> Therefore, no paddings are needed which avoids any potential issues
> with the paddings and the signature algorithm would be very simple.

You could also use SHAKE in PSS to replace MGF1. This is probably
desirable if you intent to use PSS with SHA-3.

PSS doesn't really have any padding in the traditional sense. That is,
all the padding is somehow either hashed or xored with a hashed value.
I don't think any of the padding-related issues apply in any way to
PSS, if you disagree please explain.

(shameless plug: I wrote my thesis about PSS, in case anyone wants to
read it: https://rsapss.hboeck.de/ - it's been a while, don't be too
hard on me if I made mistakes)


--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Hanno Böck]

On Thu, 3 Mar 2016 13:35:46 +
"Dang, Quynh (Fed)"  wrote:

> Why don't we use an even more elegant RSA signature called "
> full-domain hash RSA signature" ?

Full Domain Hashing was originally developed by Rogaway and Bellare and
then later dismissed because they found that they could do better. Then
they developed PSS.

See
http://web.cs.ucdavis.edu/~rogaway/papers/exact.pdf

So in essence FDH is a predecessor of PSS and the authors of both
schemes came to the conclusion that PSS is the superior scheme.


> As you know, a SHAKE (as a variable output-length hash function)
> naturally produces a hash value which fits any given modulus size.
> Therefore, no paddings are needed which avoids any potential issues
> with the paddings and the signature algorithm would be very simple. 

You could also use SHAKE in PSS to replace MGF1. This is probably
desirable if you intent to use PSS with SHA-3.

PSS doesn't really have any padding in the traditional sense. That is,
all the padding is somehow either hashed or xored with a hashed value.
I don't think any of the padding-related issues apply in any way to
PSS, if you disagree please explain.

(shameless plug: I wrote my thesis about PSS, in case anyone wants to
read it: https://rsapss.hboeck.de/ - it's been a while, don't be too
hard on me if I made mistakes)


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpbuzHpqru9V.pgp
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Dang, Quynh (Fed)]

Hi all,

Why don't we use an even more elegant RSA signature called " full-domain hash 
RSA signature" ?

As you know, a SHAKE (as a variable output-length hash function) naturally 
produces a hash value which fits any given modulus size. Therefore, no paddings 
are needed which avoids any potential issues with the paddings and the 
signature algorithm would be very simple. 

Regards,
Quynh. 


From: TLS <tls-boun...@ietf.org> on behalf of Dave Garrett 
<davemgarr...@gmail.com>
Sent: Wednesday, March 2, 2016 4:16 PM
To: tls@ietf.org
Subject: Re: [TLS] RSA-PSS in TLS 1.3

On Wednesday, March 02, 2016 01:57:48 am Viktor Dukhovni wrote:
> adaptive attacks are I think a greater potential
> threat against interactive TLS than against a bunch of CA-authored
> bits at rest.

+1

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Yoav Nir]

> On 2 Mar 2016, at 5:57 PM, Eric Rescorla  wrote:
> 
> 
> 
> On Wed, Mar 2, 2016 at 1:25 AM, Yoav Nir  > wrote:
> 
> > On 2 Mar 2016, at 11:16 AM, Rob Stradling  > > wrote:
> >
> > On 02/03/16 09:10, Rob Stradling wrote:
> > 
> >>> Neither you nor I can post in any of the CA/Browser forum’s lists,
> >>> because neither of us has either a browser or a public CA.
> >>>
> >>> There are some people who are active there and are reading this list,
> >>> so they might take such a proposal there. I’m not very optimistic,
> >>> though.
> >>
> >> Please don't give up without even trying!
> >>
> >> If you have a proposal, I'd be happy to post it to the
> >> pub...@cabforum.org  list on your behalf.
> >
> > Oh, somebody else beat me to it:
> >
> > https://cabforum.org/pipermail/public/2016-March/006910.html 
> > 
> 
> Right. And the response was that while PSS in in NSS, it’s not in Firefox. No 
> word on the other browsers out there, and definitely no word on a bunch of 
> non-browser clients that connect to servers using certificates from the 
> public CA.
> 
> For what it's worth, I expect PSS support to appear in Firefox sometime in the
> not too distant future, since it's clear we need it for 1.3 and it's not much 
> effort
> to add it for 1.2 and below.

I expect the version of our firewall that comes out in 2017 will support PSS as 
well in TLS and the PKI. The enterprise CA part of the product?  Probably not 
because it has to support the legacy.

Yoav


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Yoav Nir]

> On 2 Mar 2016, at 11:16 AM, Rob Stradling  wrote:
> 
> On 02/03/16 09:10, Rob Stradling wrote:
> 
>>> Neither you nor I can post in any of the CA/Browser forum’s lists,
>>> because neither of us has either a browser or a public CA.
>>> 
>>> There are some people who are active there and are reading this list,
>>> so they might take such a proposal there. I’m not very optimistic,
>>> though.
>> 
>> Please don't give up without even trying!
>> 
>> If you have a proposal, I'd be happy to post it to the
>> pub...@cabforum.org list on your behalf.
> 
> Oh, somebody else beat me to it:
> 
> https://cabforum.org/pipermail/public/2016-March/006910.html

Right. And the response was that while PSS in in NSS, it’s not in Firefox. No 
word on the other browsers out there, and definitely no word on a bunch of 
non-browser clients that connect to servers using certificates from the public 
CA.

I totally understand that the commercial CAs cannot afford to deprecate PKCS#1 
now. It might be prudent to announce some long-term deprecation plan such as 
the one for SHA-1 signatures.

We can hope that by the time the transition is complete RSA will have been 
abandoned in favor of ECDSA and/or EDDSA, but I would not bet on it.

Yoav

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Rob Stradling]

On 02/03/16 09:10, Rob Stradling wrote:


Neither you nor I can post in any of the CA/Browser forum’s lists,
because neither of us has either a browser or a public CA.

There are some people who are active there and are reading this list,
so they might take such a proposal there. I’m not very optimistic,
though.


Please don't give up without even trying!

If you have a proposal, I'd be happy to post it to the
pub...@cabforum.org list on your behalf.


Oh, somebody else beat me to it:

https://cabforum.org/pipermail/public/2016-March/006910.html

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Rob Stradling]

On 01/03/16 19:20, Yoav Nir wrote:


On 1 Mar 2016, at 8:23 PM, Alyssa Rowan  wrote:



When a CA issues a certificate it has to work with every client
and server out there,


That doesn't have to be true.  For example, many OpenSSL-based servers 
can be configured to serve an ECC certificate to TLS clients that 
indicate support for ECC, and to serve an RSA certificate to other TLS 
clients.



When we use TLS 1.3, the other side supports
TLS 1.3 as well, so it’s fair to assume that it knows PSS.


Perhaps the PKIX working group and CAB/Forum could both use a friendly
reminder not to ignore how perilous using RSA PKCS#1 v1.5 still remains?


+1


Neither you nor I can post in any of the CA/Browser forum’s lists, because 
neither of us has either a browser or a public CA.

There are some people who are active there and are reading this list, so they 
might take such a proposal there. I’m not very optimistic, though.


Please don't give up without even trying!

If you have a proposal, I'd be happy to post it to the 
pub...@cabforum.org list on your behalf.


Alternatively, you could post it to the questi...@cabforum.org list 
yourself.




--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Viktor Dukhovni]

On Wed, Mar 02, 2016 at 08:37:46AM +0200, Yoav Nir wrote:

> Because this is a particular field that we control.

Which is in itself a reasonable argument for leaving legacy behind,
...  but also because adaptive attacks are I think a greater potential
threat against interactive TLS than against a bunch of CA-authored
bits at rest.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Yoav Nir]

> On 2 Mar 2016, at 3:03 AM, Andrey Jivsov  wrote:
> 
> On 03/01/2016 11:20 AM, Yoav Nir wrote:
>> 
>> On 1 Mar 2016, at 8:23 PM, Alyssa Rowan  wrote:
>> 
 [YN] It would be cool to ban PKCS#1.5 from certificates, but we
 are not the PKIX working group. Nor are we the CA/Browser forum.
 When a CA issues a certificate it has to work with every client
 and server out there, When we use TLS 1.3, the other side supports
 TLS 1.3 as well, so it’s fair to assume that it knows PSS.
>>> 
>>> Perhaps the PKIX working group and CAB/Forum could both use a friendly
>>> reminder not to ignore how perilous using RSA PKCS#1 v1.5 still remains?
>> 
>> Neither you nor I can post in any of the CA/Browser forum’s lists, because 
>> neither of us has either a browser or a public CA.
>> 
>> There are some people who are active there and are reading this list, so 
>> they might take such a proposal there. I’m not very optimistic, though. 
>> While only CAs and browsers are members, they are keenly aware that even the 
>> public CAs have a wide variety of relying parties, running all sorts of 
>> software. And it’s much harder to scan clients than it is to scan servers, 
>> so it’s difficult to say how many clients will not be able to connect to a 
>> server with a certificate signed with RSA-PSS. Probably far too many for the 
>> CA/BF to be comfortable deprecating PKCS#1.
>> 
>> The PKIX working group has shut down several years ago. The Curdle WG is a 
>> new working group whose charter includes deprecating obsolete stuff. Perhaps 
>> they might be interested.
>> 
>> Yoav
>> 
> 
> The removal of PKCS #1.5 signature support in TLS 1.3 is a client issue when 
> client authentication is used. See examples here: 
> https://www.ietf.org/mail-archive/web/tls/current/msg19096.html .
> 
> Regarding server-only authentication, it seems that there is assumption that 
> TLS 1.3 will continue to use PKCS#1.5 for a long time in X.509 certs. Then 
> why "break Internet" or slow down adoption of TLS 1.3 by mandating PSS in one 
> field of handshake?

The easy answer is: because we can. We can’t mandate for the CA industry what 
kind of certificates they should issue, or rather, we can, but they’ll rightly 
ignore us. We *can* mandate how a new TLS 1.3 implementation signs for another 
new TLS 1.3 implementation. Mandating that the certificates are signed with PSS 
would definitely slow down the adoption of TLS 1.3. Mandating what algorithm is 
used within the protocol does not. 

As long as the spec allows PKCS#1 all implementations will support it and many 
implementors will delay PSS because it’s not needed for interoperability. 
That’s what a rational manager would do: implement TLS 1.3 with PKCS#1 now, and 
place implementing PSS “on the roadmap”. I don’t think we should give them that 
incentive.

> Imagine that there is PSS#2 in the future. Is the intent to issue new TLS 1.4 
> that bans PSS and hardwires PSS#2? If not, there may still be a signature 
> negotiation mechanism in TLS 1.3 in the future.

That depends. Did we find that PSS is insecure in this future? 

> The reasons CAs are cold to adoption of PSS are similar to these of TLS 
> servers or clients: 3d-party dependence, prior investment, FIPS 140 
> certification, cost.

Both servers and clients tend to use libraries that implement both the protocol 
and the algorithms. OpenSSL springs to mind, as do NSS, GNUTLS, SChannel and 
whatever Apple calls their library. Sure there are separate libraries with 
software handshakes and hardware algorithms. Even OpenSSL does this with their 
“engines”. I don’t think this is reason enough to keep dragging obsolete 
algorithms with us.

> TLS WG can ban PKCS #1.5 in CA certs in TLS 1.3, but it wisely doesn't. Why 
> one signature field is an exception? IMO this will lead to slower adoption of 
> TLS 1.3, on balance. Nothing prevents e.g. OpenSSL from implementing PSS in 
> HS (which is proposed as MUST anyway). Nothing prevents servers from not 
> negotiating TLS 1.3.

Because this is a particular field that we control.

Yoav

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Yoav Nir]

On 1 Mar 2016, at 8:23 PM, Alyssa Rowan  wrote:

> > [YN] It would be cool to ban PKCS#1.5 from certificates, but we
> > are not the PKIX working group. Nor are we the CA/Browser forum.
> > When a CA issues a certificate it has to work with every client
> > and server out there, When we use TLS 1.3, the other side supports
> > TLS 1.3 as well, so it’s fair to assume that it knows PSS.
> 
> Perhaps the PKIX working group and CAB/Forum could both use a friendly
> reminder not to ignore how perilous using RSA PKCS#1 v1.5 still remains?

Neither you nor I can post in any of the CA/Browser forum’s lists, because 
neither of us has either a browser or a public CA. 

There are some people who are active there and are reading this list, so they 
might take such a proposal there. I’m not very optimistic, though. While only 
CAs and browsers are members, they are keenly aware that even the public CAs 
have a wide variety of relying parties, running all sorts of software. And it’s 
much harder to scan clients than it is to scan servers, so it’s difficult to 
say how many clients will not be able to connect to a server with a certificate 
signed with RSA-PSS. Probably far too many for the CA/BF to be comfortable 
deprecating PKCS#1.  

The PKIX working group has shut down several years ago. The Curdle WG is a new 
working group whose charter includes deprecating obsolete stuff. Perhaps they 
might be interested.

Yoav 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Yoav Nir]

> On 1 Mar 2016, at 6:56 AM, Martin Thomson  wrote:
> 
> On 1 March 2016 at 04:32, Joseph Salowey  wrote:
>> We make RSA-PSS mandatory to implement (MUST implement instead of MUST
>> offer).   Clients can advertise support for PKCS-1.5 for backwards
>> compatibility in the transition period.
> 
>> From my perspective, this is fine.  I would like to say that we won't
> ever support PKCS#1.5 for TLS 1.3, but I think that I would rather
> have users on 1.3 with PKCS#1.5 than have them stuck on 1.2.
> 
> It seems like others are taking the position that we should say "MUST
> NOT use PKCS#1.5”.  

I’d go even further. I’d remove the rsapss(4) value from SignatureAlgorithm, 
leaving just rsa(1), and say that in TLS 1.3 an RSA signature is PSS just as it 
was PKCS#1.5 in TLS 1.2.

Certificates are a different issue altogether.

Yoav


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Nikos Mavrogiannopoulos]

On Mon, 2016-02-29 at 09:32 -0800, Joseph Salowey wrote:
> We seem to have good consensus on moving to RSA-PSS and away from
> PKCS-1.5 in TLS 1.3.  However, there is a problem that it may take
> some hardware implementations some time to move to RSA-PSS.  After an
> off list discussion with a few folks here is a proposal for moving
> forward.  
> 
> We make RSA-PSS mandatory to implement (MUST implement instead of
> MUST offer).   Clients can advertise support for PKCS-1.5 for
> backwards compatibility in the transition period.   
> Please respond on the list on whether you think this is a reasonable
> way forward or not.  

The mandatory to implement approach didn't help TLS 1.0 (which had a
DHE-RSA ciphersuite implemented by no-one for several years). If you
want to push for RSA-PSS, then please only define RSA-PSS. That, in
addition would allow to prevent that sharing of keys between TLS 1.2
and TLS 1.3 (i.e., prevent any cross-protocol attacks).

regards,
Nikos

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Martin Thomson]

On 1 March 2016 at 16:06, Viktor Dukhovni  wrote:
>> It is much easier to mandate PSS in TLS 1.3 now, than to remove it
>> later.  Servers that can't do PSS will use TLS 1.2.  This avoids
>> a break-the-web day.
>
> Sorry, ... than to remove *PKCS#1.5* later ...

Yes, this is true for some people, and likely it will be more true in
the future.  However, a MUST implement PSS is enough for me.  If it
seems like consensus is against this position, I'll back that all the
way.  However, on the web side of things, we've some experience with
killing stuff that we don't like.  It's not always painless (see
SHA-1), but I'd rather rely on that system than risk holding back 1.3.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Viktor Dukhovni]

On Tue, Mar 01, 2016 at 04:59:47AM +, Viktor Dukhovni wrote:

> It is much easier to mandate PSS in TLS 1.3 now, than to remove it
> later.  Servers that can't do PSS will use TLS 1.2.  This avoids
> a break-the-web day.

Sorry, ... than to remove *PKCS#1.5* later ...

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Martin Thomson]

On 1 March 2016 at 04:32, Joseph Salowey  wrote:
> We make RSA-PSS mandatory to implement (MUST implement instead of MUST
> offer).   Clients can advertise support for PKCS-1.5 for backwards
> compatibility in the transition period.

>From my perspective, this is fine.  I would like to say that we won't
ever support PKCS#1.5 for TLS 1.3, but I think that I would rather
have users on 1.3 with PKCS#1.5 than have them stuck on 1.2.

It seems like others are taking the position that we should say "MUST
NOT use PKCS#1.5".  I would love for that to be the case, but I want
to separate decision path for that, preferably one that is somewhat
under my control.  Once we have information about usage for each
signature scheme, I'll be happy to arrange for another "break the web"
day.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Andrey Jivsov]

On 02/29/2016 02:36 PM, Hanno Böck wrote:

We have an RFC for PSS since 2003.
We had several attacks showing the weakness of PKCS #1 1.5.


In the face of such danger, what's your opinion on PKCS #1.5 signatures 
being perfectly fine in TLS 1.3 ? I refer to signatures in X.509 certs 
in the latest https://tools.ietf.org/html/draft-ietf-tls-tls13-11.


Why not ban PKCS #1.5 altogether from TLS 1.3? It will not only make TLS 
1.3 more secure, but code simpler and footprint smaller. Besides, it's 
reasonable: TLS 1.2 already allows PSS in X.509 certs.


You are arguing for the benefit of suddenly mandating a steel door on a 
grass hut. Joseph Salowey's proposal gives an option for the door, 
consistent with how TLS 1.2 does this for X.509 certs.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Hanno Böck]

On Mon, 29 Feb 2016 12:35:57 -0800
Andrey Jivsov  wrote:

> Without a generous advance warning about PKCS#1.5 removal by TLS 1.3,
> we have to deal with already deployed hardware. Had vendors and
> customers knew that TLS 1.3 will remove PKCS #1.5, we probably would
> have ended up with more PSS-friendly Internet.

Ok, look, I really would like to understand what you're trying to say
here.

What would such a warning look like? We have an RFC for PSS since 2003.
We had several attacks showing the weakness of PKCS #1 1.5. Wasn't that
warning enough? If not, how would such a warning look like? I'd really
like to know, because we will have similar situations in the future
and I'd like to avoid people lobbying in the background to continue
supporting weak crypto.

There will be some new TLS version some day and we will try to get
better algorithms into it. So how do we warn you next time?

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpNpM6LT2ltE.pgp
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Andrey Jivsov]

On 02/29/2016 09:32 AM, Joseph Salowey wrote:
> We seem to have good consensus on moving to RSA-PSS and away from
> PKCS-1.5 in TLS 1.3.  However, there is a problem that it may take some
> hardware implementations some time to move to RSA-PSS.  After an off
> list discussion with a few folks here is a proposal for moving forward.
>
> We make RSA-PSS mandatory to implement (MUST implement instead of MUST
> offer).   Clients can advertise support for PKCS-1.5 for backwards
> compatibility in the transition period.
> Please respond on the list on whether you think this is a reasonable way
> forward or not.

I think that supporting PKCS1.5 fallback is the right thing to do for 
wider adoption of TLS 1.3, as specified above.


PKCS #1.5 is allowed by 
https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-6.3.2.1 in 
X.509 certificates. X.509 certificate chain is a part of TLS handshake. 
The above proposal is about not restricting one type of signature, the 
end-entity signature, to PSS. This applies to client authentication, 
server authentication, or both.


Without a generous advance warning about PKCS#1.5 removal by TLS 1.3, we 
have to deal with already deployed hardware. Had vendors and customers 
knew that TLS 1.3 will remove PKCS #1.5, we probably would have ended up 
with more PSS-friendly Internet. Even now PKCS#1.5 is allowed by FIPS 
140, Common Criteria, and in CA certificates in TLS 1.3, and earlier TLS.


The WG can chose to remove PSS from one type of signature in TLS1.3. 
This will result in affected implementations capping negotiation at TLS 
1.2. There is no other fix in some cases.


For more details: 
https://www.ietf.org/mail-archive/web/tls/current/msg19096.html


(I posted earlier, but don't see the message. Sending this one more 
time, slightly edited)


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RSA-PSS in TLS 1.3

[Viktor Dukhovni]

On Mon, Feb 29, 2016 at 09:32:04AM -0800, Joseph Salowey wrote:

> We seem to have good consensus on moving to RSA-PSS and away from PKCS-1.5
> in TLS 1.3.  However, there is a problem that it may take some hardware
> implementations some time to move to RSA-PSS.  After an off list discussion
> with a few folks here is a proposal for moving forward.
> 
> We make RSA-PSS mandatory to implement (MUST implement instead of MUST
> offer).   Clients can advertise support for PKCS-1.5 for backwards
> compatibility in the transition period.
> Please respond on the list on whether you think this is a reasonable way
> forward or not.

My instinct is to mandate PSS and let PKCS#1 rest in peace.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls