[openssl.org #2464] TLS-RSA-PSK support

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[openssl.org #2464] TLS-RSA-PSK support

Rich Salz via RT
Yet another version after some refactorings that landed in master.

Please, pretty please, with sugar on top, could anyone review this code
so that it can get merged?

It's becoming a difficult exercise to keep track of upstream changes and
adapt the patch every single time...

Cheers,
--
Giuseppe D'Angelo | [hidden email] | Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

0001-Introduce-TLS-RSA-PSK-support.patch (32K) Download Attachment
smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #2464] TLS-RSA-PSK support

Viktor Dukhovni
On Sun, Jun 21, 2015 at 07:00:55PM +0000, Giuseppe D'Angelo via RT wrote:

> diff --git a/doc/apps/ciphers.pod b/doc/apps/ciphers.pod
> index c2d40ac..7fbe3a4 100644
> --- a/doc/apps/ciphers.pod
> +++ b/doc/apps/ciphers.pod
> @@ -585,10 +585,22 @@ Note: these ciphers can also be used in SSL v3.
>  
>  =head2 Pre shared keying (PSK) ciphersuites
>  
> + TLS_RSA_PSK_WITH_RC4_128_SHA              RSA-PSK-RC4-SHA
> + TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA         RSA-PSK-3DES-EDE-CBC-SHA
> + TLS_RSA_PSK_WITH_AES_128_CBC_SHA          RSA-PSK-AES128-CBC-SHA
> + TLS_RSA_PSK_WITH_AES_256_CBC_SHA          RSA-PSK-AES256-CBC-SHA
> + TLS_RSA_PSK_WITH_AES_128_CBC_SHA256       RSA-PSK-AES128-CBC-SHA256
> + TLS_RSA_PSK_WITH_AES_256_CBC_SHA384       RSA-PSK-AES256-CBC-SHA384
> + TLS_RSA_PSK_WITH_AES_128_GCM_SHA256       RSA-PSK-AES128-GCM-SHA256
> + TLS_RSA_PSK_WITH_AES_256_GCM_SHA384       RSA-PSK-AES256-GCM-SHA384
>   TLS_PSK_WITH_RC4_128_SHA                  PSK-RC4-SHA
>   TLS_PSK_WITH_3DES_EDE_CBC_SHA             PSK-3DES-EDE-CBC-SHA
>   TLS_PSK_WITH_AES_128_CBC_SHA              PSK-AES128-CBC-SHA
>   TLS_PSK_WITH_AES_256_CBC_SHA              PSK-AES256-CBC-SHA
> + TLS_PSK_WITH_AES_128_CBC_SHA256           PSK-AES128-CBC-SHA256
> + TLS_PSK_WITH_AES_256_CBC_SHA384           PSK-AES256-CBC-SHA384
> + TLS_PSK_WITH_AES_128_GCM_SHA256           PSK-AES128-GCM-SHA256
> + TLS_PSK_WITH_AES_256_GCM_SHA384           PSK-AES256-GCM-SHA384

Question, should we really be adding new RC4 or new 3DES ciphersuites?
Both ciphers are rather obsolete now.  And we even have an RFC that
"bans" RC4.  While I have been known to resist potentially premature
removal of *existing* RC4 support, I am certainly not a fan of RC4
and see no reason to add more RC4 to OpenSSL.

And while 3DES seems to be holding up moderately well for its age,
I see no reason to add more 3DES ciphersuites.

Therefore, I would to propose that the 3DES and RC4 PSK ciphersuites
not be included.

I am not even sure that adding Camellia is a net win, ideally AES
and (soonish) ChaCha20 are enough.

One might similarly question the longevity of the new CBC suites,
TLS 1.3 is moving to AEAD only (the PSK AEAD ciphers will IIRC be
used for session resumption in 1.3).

How many of the new ciphersuites are used/needed in practice? Which
are MTI for PSK?  I think that when adding ciphersuites, we have
the opportunity/responsibility to exercise good judgement and enable
only the essential ones, and try to keep a lid on needless ciphersuite
proliferation.

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #2464] TLS-RSA-PSK support

Salz, Rich

> Therefore, I would to propose that the 3DES and RC4 PSK ciphersuites not be
> included.
>
> I am not even sure that adding Camellia is a net win, ideally AES and (soonish)
> ChaCha20 are enough.
>
> One might similarly question the longevity of the new CBC suites, TLS 1.3 is
> moving to AEAD only (the PSK AEAD ciphers will IIRC be used for session
> resumption in 1.3).

What Viktor said.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #2464] TLS-RSA-PSK support

Hubert Kario
In reply to this post by Viktor Dukhovni
On Thursday 30 July 2015 15:09:18 Viktor Dukhovni wrote:

> On Sun, Jun 21, 2015 at 07:00:55PM +0000, Giuseppe D'Angelo via RT wrote:
> > diff --git a/doc/apps/ciphers.pod b/doc/apps/ciphers.pod
> > index c2d40ac..7fbe3a4 100644
> > --- a/doc/apps/ciphers.pod
> > +++ b/doc/apps/ciphers.pod
> > @@ -585,10 +585,22 @@ Note: these ciphers can also be used in SSL v3.
> >
> >  =head2 Pre shared keying (PSK) ciphersuites
> >
> > + TLS_RSA_PSK_WITH_RC4_128_SHA              RSA-PSK-RC4-SHA
> > + TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA         RSA-PSK-3DES-EDE-CBC-SHA
> > + TLS_RSA_PSK_WITH_AES_128_CBC_SHA          RSA-PSK-AES128-CBC-SHA
> > + TLS_RSA_PSK_WITH_AES_256_CBC_SHA          RSA-PSK-AES256-CBC-SHA
> > + TLS_RSA_PSK_WITH_AES_128_CBC_SHA256       RSA-PSK-AES128-CBC-SHA256
> > + TLS_RSA_PSK_WITH_AES_256_CBC_SHA384       RSA-PSK-AES256-CBC-SHA384
> > + TLS_RSA_PSK_WITH_AES_128_GCM_SHA256       RSA-PSK-AES128-GCM-SHA256
> > + TLS_RSA_PSK_WITH_AES_256_GCM_SHA384       RSA-PSK-AES256-GCM-SHA384
> >
> >   TLS_PSK_WITH_RC4_128_SHA                  PSK-RC4-SHA
> >   TLS_PSK_WITH_3DES_EDE_CBC_SHA             PSK-3DES-EDE-CBC-SHA
> >   TLS_PSK_WITH_AES_128_CBC_SHA              PSK-AES128-CBC-SHA
> >   TLS_PSK_WITH_AES_256_CBC_SHA              PSK-AES256-CBC-SHA
> >
> > + TLS_PSK_WITH_AES_128_CBC_SHA256           PSK-AES128-CBC-SHA256
> > + TLS_PSK_WITH_AES_256_CBC_SHA384           PSK-AES256-CBC-SHA384
> > + TLS_PSK_WITH_AES_128_GCM_SHA256           PSK-AES128-GCM-SHA256
> > + TLS_PSK_WITH_AES_256_GCM_SHA384           PSK-AES256-GCM-SHA384
>
> Question, should we really be adding new RC4 or new 3DES ciphersuites?
> Both ciphers are rather obsolete now.  And we even have an RFC that
> "bans" RC4.  While I have been known to resist potentially premature
> removal of *existing* RC4 support, I am certainly not a fan of RC4
> and see no reason to add more RC4 to OpenSSL.
those are PSK ciphers, unless you set up PSK they won't be advertised at all,
adding support for them has minimal impact on Internet use (be it port 443 or
otherwise) of RC4 and 3DES

and for people that actually need this support, it's better that they use
OpenSSL than a home-cooked solution by an intern

> I am not even sure that adding Camellia is a net win, ideally AES
> and (soonish) ChaCha20 are enough.

Camellia is the recommended backup cipher by ENISA, rightfully so

> One might similarly question the longevity of the new CBC suites,
> TLS 1.3 is moving to AEAD only (the PSK AEAD ciphers will IIRC be
> used for session resumption in 1.3).

I give them 20 years, ok... 30 years tops
 
> How many of the new ciphersuites are used/needed in practice? Which
> are MTI for PSK?  I think that when adding ciphersuites, we have
> the opportunity/responsibility to exercise good judgement and enable
> only the essential ones, and try to keep a lid on needless ciphersuite
> proliferation.

this horse left the barn, the barn got overgrown, people cut the trees and now
are building a new barn

--
Regards,
Hubert Kario
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
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #2464] TLS-RSA-PSK support

Viktor Dukhovni
On Fri, Jul 31, 2015 at 07:24:15PM +0200, Hubert Kario wrote:

> > Question, should we really be adding new RC4 or new 3DES ciphersuites?
> > Both ciphers are rather obsolete now.  And we even have an RFC that
> > "bans" RC4.  While I have been known to resist potentially premature
> > removal of *existing* RC4 support, I am certainly not a fan of RC4
> > and see no reason to add more RC4 to OpenSSL.
>
> those are PSK ciphers, unless you set up PSK they won't be advertised at all,
> adding support for them has minimal impact on Internet use (be it port 443 or
> otherwise) of RC4 and 3DES
>
> and for people that actually need this support, it's better that they use
> OpenSSL than a home-cooked solution by an intern

I know all that, but do they in fact need RC4 or 3DES, or are we
just putting them in because they have code-point assignments in
the RFC?

> > I am not even sure that adding Camellia is a net win, ideally AES
> > and (soonish) ChaCha20 are enough.
>
> Camellia is the recommended backup cipher by ENISA, rightfully so

Fine.

> > One might similarly question the longevity of the new CBC suites,
> > TLS 1.3 is moving to AEAD only (the PSK AEAD ciphers will IIRC be
> > used for session resumption in 1.3).
>
> I give them 20 years, ok... 30 years tops

Yes, hence the "might".  The point is that I am suggesting some
consideration of what's actually needed before new ciphers are
implemented.  Mere inclusion in a somewhat dated RFC is perhaps
not compelling.

Which ciphers are actually needed by PSK users?  My hope is that
at this point RC4 and 3DES are not.  It is highly likely that CBC
AES-CBC is needed, perhaps also Camellia, but the question is I
think worth asking.

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #2464] TLS-RSA-PSK support

Viktor Dukhovni
On Fri, Jul 31, 2015 at 05:37:20PM +0000, Viktor Dukhovni wrote:

> Which ciphers are actually needed by PSK users?  My hope is that
> at this point RC4 and 3DES are not.  It is highly likely that CBC
> AES-CBC is needed, perhaps also Camellia, but the question is I
> think worth asking.

So what's the final resolution of this?  Should we keep or drop
the new PSK RC4 and PSK 3DES codepoints:

    TLS_RSA_PSK_WITH_RC4_128_SHA              RSA-PSK-RC4-SHA
    TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA         RSA-PSK-3DES-EDE-CBC-SHA

On a related note (for those also reading the TLS WG list), any
thoughts on deprecating any or all of the kDHr, kDHd, kECDHr, kECDHe
ciphers?

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #2464] TLS-RSA-PSK support

Salz, Rich
>     TLS_RSA_PSK_WITH_RC4_128_SHA              RSA-PSK-RC4-SHA
>     TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA         RSA-PSK-3DES-EDE-CBC-
> SHA


Remove.

> On a related note (for those also reading the TLS WG list), any thoughts on
> deprecating any or all of the kDHr, kDHd, kECDHr, kECDHe ciphers?

Remove.

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #2464] TLS-RSA-PSK support

Hubert Kario
In reply to this post by Viktor Dukhovni
On Monday 17 August 2015 15:54:03 Viktor Dukhovni wrote:

> On Fri, Jul 31, 2015 at 05:37:20PM +0000, Viktor Dukhovni wrote:
> > Which ciphers are actually needed by PSK users?  My hope is that
> > at this point RC4 and 3DES are not.  It is highly likely that CBC
> > AES-CBC is needed, perhaps also Camellia, but the question is I
> > think worth asking.
>
> So what's the final resolution of this?  Should we keep or drop
> the new PSK RC4 and PSK 3DES codepoints:
>
>     TLS_RSA_PSK_WITH_RC4_128_SHA              RSA-PSK-RC4-SHA
>     TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA         RSA-PSK-3DES-EDE-CBC-SHA
how do you define "remove"?

 1. not part of DEFAULT, part of ALL?
 2. part of COMPLEMENTOFALL
 3. behind compile time option
 4. behind #if 0
 5. actually removed from source

1-3 are fine by me, 4 I wouldn't like, I'm against 5

> On a related note (for those also reading the TLS WG list), any
> thoughts on deprecating any or all of the kDHr, kDHd, kECDHr, kECDHe
> ciphers?

if "deprecate" means 1) or 2), I'm all for it
--
Regards,
Hubert Kario
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
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #2464] TLS-RSA-PSK support

Viktor Dukhovni
On Tue, Aug 18, 2015 at 06:48:25PM +0200, Hubert Kario wrote:

> > So what's the final resolution of this?  Should we keep or drop
> > the new PSK RC4 and PSK 3DES codepoints:
> >
> >     TLS_RSA_PSK_WITH_RC4_128_SHA              RSA-PSK-RC4-SHA
> >     TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA         RSA-PSK-3DES-EDE-CBC-SHA
>
> how do you define "remove"?
>
>  1. not part of DEFAULT, part of ALL?
>  2. part of COMPLEMENTOFALL
>  3. behind compile time option
>  4. behind #if 0
>  5. actually removed from source
>
> 1-3 are fine by me, 4 I wouldn't like, I'm against 5

These are brand new cipher suites, never before seen in OpenSSL.
The argument is that it makes no sense to *add* these, because
they're already obsolete.  So I was hoping for 4 or 5.

> > On a related note (for those also reading the TLS WG list), any
> > thoughts on deprecating any or all of the kDHr, kDHd, kECDHr, kECDHe
> > ciphers?
>
> if "deprecate" means 1) or 2), I'm all for it

For these, I'd like to suggest at least 2, but is there any need
to actually support the underlying static (EC)DH key exchange
methods?  Who needs these?  Why work so hard to defeat forward
secrecy and enable the KCI attacks?

We can lose a bunch of code and attack surface by not supporting
fixed (EC)DH.  Does this code have any users?

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #2464] TLS-RSA-PSK support

Salz, Rich
> These are brand new cipher suites, never before seen in OpenSSL.
> The argument is that it makes no sense to *add* these, because they're
> already obsolete.  So I was hoping for 4 or 5.

Strongly agree.

> We can lose a bunch of code and attack surface by not supporting fixed
> (EC)DH.  Does this code have any users?

Perhaps posting to openssl-users, like we've done in the past about platforms and other #ifdef's?
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #2464] TLS-RSA-PSK support

Hubert Kario
In reply to this post by Viktor Dukhovni
On Tuesday 18 August 2015 17:02:24 Viktor Dukhovni wrote:

> On Tue, Aug 18, 2015 at 06:48:25PM +0200, Hubert Kario wrote:
> > > So what's the final resolution of this?  Should we keep or drop
> > >
> > > the new PSK RC4 and PSK 3DES codepoints:
> > >     TLS_RSA_PSK_WITH_RC4_128_SHA              RSA-PSK-RC4-SHA
> > >     TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA         RSA-PSK-3DES-EDE-CBC-SHA
> >
> > how do you define "remove"?
> >
> >  1. not part of DEFAULT, part of ALL?
> >  2. part of COMPLEMENTOFALL
> >  3. behind compile time option
> >  4. behind #if 0
> >  5. actually removed from source
> >
> > 1-3 are fine by me, 4 I wouldn't like, I'm against 5
>
> These are brand new cipher suites, never before seen in OpenSSL.
they are brand new only in OpenSSL, not in general

> The argument is that it makes no sense to *add* these, because
> they're already obsolete.  So I was hoping for 4 or 5.

If you have a server or a client which needs to interoperate with both very
old systems and new systems, you need both obsolete and modern ciphers at the
same time.

as long as OpenSSL ships support for single DES by default, giving those
ciphers the treatment 4 is... inconsistent... to put it mildly.

> > > On a related note (for those also reading the TLS WG list), any
> > > thoughts on deprecating any or all of the kDHr, kDHd, kECDHr, kECDHe
> > > ciphers?
> >
> > if "deprecate" means 1) or 2), I'm all for it
>
> For these, I'd like to suggest at least 2, but is there any need
> to actually support the underlying static (EC)DH key exchange
> methods?  Who needs these?  Why work so hard to defeat forward
> secrecy and enable the KCI attacks?
>
> We can lose a bunch of code and attack surface by not supporting
> fixed (EC)DH.  Does this code have any users?
I've heard that there are servers which support those exclusively, so yes,
they do have users. But I can't point at an example server as I haven't seen
them in Alexa top 1M.

--
Regards,
Hubert Kario
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
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #2464] TLS-RSA-PSK support

Viktor Dukhovni
On Wed, Aug 19, 2015 at 02:59:59PM +0200, Hubert Kario wrote:

> > > > So what's the final resolution of this?  Should we keep or drop
> > > >
> > > > the new PSK RC4 and PSK 3DES codepoints:
> > > >     TLS_RSA_PSK_WITH_RC4_128_SHA              RSA-PSK-RC4-SHA
> > > >     TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA         RSA-PSK-3DES-EDE-CBC-SHA
> >
> > These are brand new cipher suites, never before seen in OpenSSL.
>
> they are brand new only in OpenSSL, not in general

I'm well aware of that.

> > The argument is that it makes no sense to *add* these, because
> > they're already obsolete.  So I was hoping for 4 or 5.
>
> If you have a server or a client which needs to interoperate with both very
> old systems and new systems, you need both obsolete and modern ciphers at the
> same time.

Yes, but does anyone using OpenSSL need *these*?  Clearly anyone
who's been using OpenSSL with PSK has been doing fine without them.
Are there any likely new users for these?

> as long as OpenSSL ships support for single DES by default, giving those
> ciphers the treatment 4 is... inconsistent... to put it mildly.

I see no ongoing reason to keep single DES TLS ciphersuites enabled
by default, and in fact export ciphers *and* single DES are both
deprecated with TLS 1.2, and we should make sure that TLS 1.2 never
negotiates either.  But at least with single DES there could well
be existing users of OpenSSL relying on it (at least as a block
cipher in libcrypto if not as an SSL ciphersuite).  So we can move
it to COMPLEMENTOFALL or COMPLEMENTOFDEFAULT.

Here we're discusing whether it is prudent to add *new* obsolete
code points, not retain existing ones.

> > For these, I'd like to suggest at least 2, but is there any need
> > to actually support the underlying static (EC)DH key exchange
> > methods?  Who needs these?  Why work so hard to defeat forward
> > secrecy and enable the KCI attacks?
> >
> > We can lose a bunch of code and attack surface by not supporting
> > fixed (EC)DH.  Does this code have any users?
>
> I've heard that there are servers which support those exclusively, so yes,
> they do have users. But I can't point at an example server as I haven't seen
> them in Alexa top 1M.

Perhaps the users who need these should make themselves heard.
They'll need to stay with TLS <= 1.2 forever, since IIRC 1.3 is
removing non PFS suites, perhaps they can also stay with older
versions of OpenSSL while they're at it, and we can remove
fixed (EC)DH key exchange in 1.1.0 (aka "master").

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #2464] TLS-RSA-PSK support

Salz, Rich
In reply to this post by Hubert Kario
> as long as OpenSSL ships support for single DES by default, giving those
> ciphers the treatment 4 is... inconsistent... to put it mildly.

It depends on how you look at it.

We have to move very slowly (more slowly than I would like!!) to removing things that are in the shipped software.  But we can more rapidly remove things that were never in an official release and are, by current evaluations, too weak.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev