[gnutls-devel] moving out from SHA1

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[gnutls-devel] moving out from SHA1

Nikos Mavrogiannopoulos-2
Hi,
 Given the first found collision for SHA1, I think it is time to plan
removing it from the trusted set. I do not believe we can do that
today in existing releases, as there is simply too much stuff relying
SHA1. Even for the web PKI which the transition from SHA1 was already
in place, major sites like amazon.com today provide an OCSP response
signed with RSA-SHA1.

So what I propose, is remove sha1 from the trusted set in gnutls 3.6.0
(to be released the second half of this year). That release will
forbid SHA1 from any operation unless special flags to indicate that
broken algorithms are allowed are set. My intention is not to
introduce a new flag to allow SHA1, but utilize the catch-all allow
broken algorithms flag.

In 3.5.x we forbid SHA1 for certificate verification in TLS, for the
NORMAL and above levels, in one of the next few releases (3.5.10 or
3.5.11), but still allow it for TLS handshake signatures. That is, we
take advantage of the verifcation PROFILEs associated with a priority
string keyword, and even though SHA1 is in general acceptable, it will
be refused for certificate verification. At the same time it will
allow applications which rely on SHA1 to continue function, as well as
connection to old servers which use TLS signatures with SHA1 (maybe
even treat OCSP differently to avoid breaking examples with amazon as
above).

6 months to a year later port that to the 3.3.x branch.

What do you think?

regards,
Nikos

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] moving out from SHA1

Tim Ruehsen
On Friday, February 24, 2017 10:23:31 AM CET Nikos Mavrogiannopoulos wrote:

> Hi,
>  Given the first found collision for SHA1, I think it is time to plan
> removing it from the trusted set. I do not believe we can do that
> today in existing releases, as there is simply too much stuff relying
> SHA1. Even for the web PKI which the transition from SHA1 was already
> in place, major sites like amazon.com today provide an OCSP response
> signed with RSA-SHA1.
>
> So what I propose, is remove sha1 from the trusted set in gnutls 3.6.0
> (to be released the second half of this year). That release will
> forbid SHA1 from any operation unless special flags to indicate that
> broken algorithms are allowed are set. My intention is not to
> introduce a new flag to allow SHA1, but utilize the catch-all allow
> broken algorithms flag.
>
> In 3.5.x we forbid SHA1 for certificate verification in TLS, for the
> NORMAL and above levels, in one of the next few releases (3.5.10 or
> 3.5.11), but still allow it for TLS handshake signatures. That is, we
> take advantage of the verifcation PROFILEs associated with a priority
> string keyword, and even though SHA1 is in general acceptable, it will
> be refused for certificate verification. At the same time it will
> allow applications which rely on SHA1 to continue function, as well as
> connection to old servers which use TLS signatures with SHA1 (maybe
> even treat OCSP differently to avoid breaking examples with amazon as
> above).
>
> 6 months to a year later port that to the 3.3.x branch.
>
> What do you think?
Thanks, that sounds like a reasonable plan :-)

After reading about the collision yesterday, I already though about impacts
onto the hopefully-soon-to-be-released wget2.

Just from what read / understood, there is no need to hurry (?):
They said it needed "thousands of CPU years" to generate the collision.
A very rough calculation of the costs:
- $0.01 per GFLOPShour from [1]
- 8760 hours per year
- 3000 CPU years
- assuming 50 GFLOPS per CPU
- 3000 * 8760 * 50 GFLOPShours
- 3000 * 8760 * 50 * $0.01 = 13.140.000$ !!!

Even when assuming 10x less costs per GFLOPShour, it's pretty expensive to
generate one collision. Or did I misunderstand/misread something basic ?

[1] http://aiimpacts.org/current-flops-prices/

Regards, Tim

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] moving out from SHA1

Nikos Mavrogiannopoulos-2
On Fri, 2017-02-24 at 11:17 +0100, Tim Ruehsen wrote:

> > In 3.5.x we forbid SHA1 for certificate verification in TLS, for
> > the
> > NORMAL and above levels, in one of the next few releases (3.5.10 or
> > 3.5.11), but still allow it for TLS handshake signatures. That is,
> > we
> > take advantage of the verifcation PROFILEs associated with a
> > priority
> > string keyword, and even though SHA1 is in general acceptable, it
> > will
> > be refused for certificate verification. At the same time it will
> > allow applications which rely on SHA1 to continue function, as well
> > as
> > connection to old servers which use TLS signatures with SHA1 (maybe
> > even treat OCSP differently to avoid breaking examples with amazon
> > as
> > above).
> >
> > 6 months to a year later port that to the 3.3.x branch.
> >
> > What do you think?
>
> Thanks, that sounds like a reasonable plan :-)
>
> After reading about the collision yesterday, I already though about
> impacts 
> onto the hopefully-soon-to-be-released wget2.
>
> Just from what read / understood, there is no need to hurry (?):
> They said it needed "thousands of CPU years" to generate the
> collision.
> A very rough calculation of the costs:
> - $0.01 per GFLOPShour from [1]
> - 8760 hours per year
> - 3000 CPU years
> - assuming 50 GFLOPS per CPU
> - 3000 * 8760 * 50 GFLOPShours
> - 3000 * 8760 * 50 * $0.01 = 13.140.000$ !!!
> Even when assuming 10x less costs per GFLOPShour, it's pretty
> expensive to 
> generate one collision. Or did I misunderstand/misread something
> basic ?

My understanding is the same; the cost for a collision is quite high.
Note that a collision itself is not catastrophic for signatures and
practical attacks are quite complex, but may still be feasible as with
md5 [0]. These attacks on MD5 showed that short time after the first
collision practical attacks could be mounted by academics.

regards,
Nikos

[0]. https://www.win.tue.nl/hashclash/rogue-ca/


_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] moving out from SHA1

Nikos Mavrogiannopoulos-2
In reply to this post by Nikos Mavrogiannopoulos-2
On Fri, Feb 24, 2017 at 10:23 AM, Nikos Mavrogiannopoulos
<[hidden email]> wrote:

> Hi,
>  Given the first found collision for SHA1, I think it is time to plan
> removing it from the trusted set. I do not believe we can do that
> today in existing releases, as there is simply too much stuff relying
> SHA1. Even for the web PKI which the transition from SHA1 was already
> in place, major sites like amazon.com today provide an OCSP response
> signed with RSA-SHA1.
>
> So what I propose, is remove sha1 from the trusted set in gnutls 3.6.0
> (to be released the second half of this year). That release will
> forbid SHA1 from any operation unless special flags to indicate that
> broken algorithms are allowed are set. My intention is not to
> introduce a new flag to allow SHA1, but utilize the catch-all allow
> broken algorithms flag.
>
> In 3.5.x we forbid SHA1 for certificate verification in TLS, for the
> NORMAL and above levels, in one of the next few releases (3.5.10 or
> 3.5.11), but still allow it for TLS handshake signatures. That is, we
> take advantage of the verifcation PROFILEs associated with a priority
> string keyword, and even though SHA1 is in general acceptable, it will
> be refused for certificate verification. At the same time it will
> allow applications which rely on SHA1 to continue function, as well as
> connection to old servers which use TLS signatures with SHA1 (maybe
> even treat OCSP differently to avoid breaking examples with amazon as
> above).

I think, that the gradual phasing out, firstly for certificates and
then for everything else makes sense also for the 3.6.0 release. SHA1
is still actively used for OCSP, DNS and possibly many other
protocols. As such I've opened the issue:
https://gitlab.com/gnutls/gnutls/issues/229
and I believe we should move more conservatively in this deprecation.
Make it happen on 3.6.0 releases only for certificates, and postpone
full phasing out few years from now.

regards,
Nikos

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Loading...