[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] security levels for TLS
[There are two different issues here: the original topic
of the thread regarding determining the overall security
of a TLS session and representing it as one of a few
"levels", and the topic I'm more interested in which is
adding the capability for a TLS client to tell the server
all of the missing parameters not specified by a cipher
suite. Adding the latter would enable the former.]
I think there is good reason to try to solve this problem
in the TLS layer. The alternative is to force every TLS-
enabled application to solve it (and likely they won't
solve it and be less secure). Wouldn't it be ideal if an
application could just say:
TLS::SetSecurityLevel (3);
No, it would not, because, I've now said several times, security is
not expressible via a single metric, making this a complete rathole.
Clearly behind the scenes, the TLS layer would translate the
single metric into the myriad options available. Some cipher
suites would only be used at level 1 or 2, say, but not at
levels 3 or 4. Higher levels would require longer RSA keys,
more DH parameter bits, etc. These profiles would change
over time to reflect the current threat levels posed by
attackers.
You've said that this is not possible because, for instance,
DES3 does not have a single value for the key length since
one attack renders its effective strength at 168 bits, while
another weakens it to 112 bits. I would say that you would
have to go with the lower 112 bits, and perhaps you wouldn't
even allow it at level 1. I have to admit I don't know the
subtleties of elliptic curve cryptography to know how to
translate "level 2" to a list of acceptable curves and key
lengths, but I'm sure someone on this list does.
Right now all cipher suites are under-specified. If we had,
for example:
TLS_DHE_1024_RSA_2048_WITH_AES_128_CBC_SHA
we would probably not be talking about this. I proposed that
we let clients "fill in the blanks" that the cipher suites
don't specify. Isn't it better to tell the server exactly
what you want in terms of security, thanietf.org with esmtp (Exim 4.43) id 1IgC51-0002xD-Qk
for tls at lists.ietf.org; Fri, 12 Oct 2007 00:25:00 -0400
Received: from sceptre (localhost.localdomain [127.0.0.1])
by sceptre.pobox.com (Postfix) with ESMTP id 67BE42EF
for <tls at lists.ietf.org>; Fri, 12 Oct 2007 00:24:53 -0400 (EDT)
Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 18D35862AD
for <tls at lists.ietf.org>; Fri, 12 Oct 2007 00:24:52 -0400 (EDT)
Message-ID: <470EF76B.5050102 at pobox.com>
Date: Thu, 11 Oct 2007 21:26:19 -0700
From: Mike <mike-list at pobox.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: tls at lists.ietf.org
Subject: Re: [TLS] security levels for TLS
References: <c331d99a0710080621g7c0ec91et35c46553c23f4402 at mail.gmail.com>
<p0624082fc331b0ed0ecc at [192.168.1.100]>
<FA998122A677CF4390C1E291BFCF59890849871E at EXCH.missi.ncsc.mil>
<470D0243.3050009 at pobox.com>
<20071010180324.7ABC533C21 at delta.rtfm.com>
<470E4399.3010008 at pobox.com>
<20071011155829.965C733C28 at delta.rtfm.com>
In-Reply-To: <20071011155829.965C733C28 at delta.rtfm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d16ce744298aacf98517bc7c108bd198
X-BeenThere: tls at lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working
group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>,
<mailto:tls-request at lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls at lists.ietf.org>
List-Help: <mailto:tls-request at lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>,
<mailto:tls-request at lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces at lists.ietf.org
[There are two different issues here: the original topic
of the thread regarding determining the overall security
of a TLS session and representing it as one of a few
"levels", and the topic I'm more interested in which is
adding the capability for a TLS client to tell the server
all of the missing parameters not specified by a cipher
suite. Adding the latter would enable the former.]
I think there is good reason to try to solve this problem
in the TLS layer. The alternative is to force every TLS-
enabled application to solve it (and likely they won't
solve it and be less secure). Wouldn't it be ideal if an
application could just say:
TLS::SetSecurityLevel (3);
No, it would not, because, I've now said several times, security is
not expressible via a single metric, making this a complete rathole.
Clearly behind the scenes, the TLS layer would translate the
single metric into the myriad options available. Some cipher
suites would only be used at level 1 or 2, say, but not at
levels 3 or 4. Higher levels would require longer RSA keys,
more DH parameter bits, etc. These profiles would change
over time to reflect the current threat levels posed by
attackers.
You've said that this is not possible because, for instance,
DES3 does not have a single value for the key length since
one attack renders its effective strength at 168 bits, while
another weakens it to 112 bits. I would say that you would
have to go with the lower 112 bits, and perhaps you wouldn't
even allow it at level 1. I have to admit I don't know the
subtleties of elliptic curve cryptography to know how to
translate "level 2" to a list of acceptable curves and key
lengths, but I'm sure someone on this list does.
Right now all cipher suites are under-specified. If we had,
for example:
TLS_DHE_1024_RSA_2048_WITH_AES_128_CBC_SHA
we would probably not be talking about this. I proposed that
we let clients "fill in the blanks" that the cipher suites
don't specify. Isn't it better to tell the server exactly
what you want in terms of security, than to leave it up to
chance? You argued that servers only have one set of
asymmetric keys, so there are no options anyway. I would
counter that there is currently no way to tell the server
that you want a 4096-bit RSA key, for example, so of course
they don't have multiple keys. Chicken/egg.
I'm an interface designer, and believe that the average
application developer has only a boolean view of security:
either security (TLS) is enabled, or it isn't. It's easy
to extend that to a 3 or 4 level security model, but beyond
that, you're asking for trouble. (A TLS toolkit would still
provide a security expert full control of course.)
Currently an application has to do the following:
1) configure TLS layer with acceptable cipher suites
2) connect to server
3) negotiate a TLS session
(many applications will stop here)
4) check that the negotiated parameters meet the
application's idea of good security
5) if not, abort TLS session, disconnect, remove
some cipher suites from the acceptable list and
goto step 1
Again, do you have any evidence this is a problem in practice.
I appreciate it's a potential problem *in theory* but that's
not the same thing.
On May 14, 2007, Yngve Pettersen of Opera Software wrote to
the TLS mailing list on the topic of "Short Ephemeral Diffie-
Hellman keys". The last paragraph illustrates this:
I have recently started to see an increasing number of reports about
SSL/TLS servers using short Ephermal Diffie-Hellman keys, in some cases
very short ones.
Opera's SSL/TLS client will display warnings to users if the server is
using RSA/DH/DSA keys shorter than (currently) 900 bits. All keys used
in the chain, including the CA certificates are included in this
evaluation, as well as the ephermal key, if the server selects a cipher
with an ephermal key.
The short DHE keys I have seen have usually been 512 bits, but I have
seen servers sending keys as short as 256 bits.
I have seen these keys on both normal webservers and mail servers, but I
have an impression that there are more reports about the mail servers.
I think it might be an idea for TLS specification to include
recommendations about how such keys should be selected.
My preference for such a recommendation is that the ephermal key should
be as long, or as strong, as the key used to sign the ephermal key. I
don't think the specification should mention specific keylengths,
because what is secure is likely to change over time.
Comments?
[this is the important part:]
As far as Opera is concerned, I am considering a few options, including
automatically disabling the ephermal ciphersuites or re-sorting the
cipher suite list toplace them last, and renegotiate the connection.
[Apparently my memory was incorrect and the session was
renegotiated instead of the close->reconnect->negotiate
sequence I stated; however, support for renegotiation is
optional, so it may not always work.]
The folks at Opera Software have expressed how difficult
it was to secure their browser, and how insecure some
servers are (256-bit DH parameters!).
Yes that's interesting but irrelevant. Those are pretty
clearly mistakes on the server side, as are RSA e values
of 1. Neither is likely to be fixed by specifying security
levels in the way you suggest.
This proves my point -- lots of application developers and/
or server operators don't understand this stuff to the level
required to make all the right choices.
Another issue I've been meaning to bring up is that
if you want forward secrecy, you need to use Diffie-
Hellman; however, there is no way to tell the server
the size of the parameter p you want. Increasing the
size of p has significant performance implications,
so servers will typically use 1024 bits.
[...] It would be better if those
who want to use 4096 bits could ask for it.
Again, please present some evidence that this is a real
practical issue outside of a very small population of
keylength fetishists.
to leave it up to
chance? You argued that servers only have one set of
asymmetric keys, so there are no options anyway. I would
counter that there is currently no way to tell the server
that you want a 4096-bit RSA key, for example, so of course
they don't have multiple keys. Chicken/egg.
I'm an interface designer, and believe that the average
application developer has only a boolean view of security:
either security (TLS) is enabled, or it isn't. It's easy
to extend that to a 3 or 4 level security model, but beyond
that, you're asking for trouble. (A TLS toolkit would still
provide a security expert full control of course.)
Currently an application has to do the following:
1) configure TLS layer with acceptable cipher suites
2) connect to server
3) negotiate a TLS session
(many applications will stop here)
4) check that the negotiated parameters meet the
application's idea of good security
5) if not, abort TLS session, disconnect, remove
some cipher suites from the acceptable list and
goto step 1
Again, do you have any evidence this is a problem in practice.
I appreciate it's a potential problem *in theory* but that's
not the same thing.
On May 14, 2007, Yngve Pettersen of Opera Software wrote to
the TLS mailing list on the topic of "Short Ephemeral Diffie-
Hellman keys". The last paragraph illustrates this:
I have recently started to see an increasing number of reports about
SSL/TLS servers using short Ephermal Diffie-Hellman keys, in some cases
very short ones.
Opera's SSL/TLS client will display warnings to users if the server is
using RSA/DH/DSA keys shorter than (currently) 900 bits. All keys used
in the chain, including the CA certificates are included in this
evaluation, as well as the ephermal key, if the server selects a cipher
with an ephermal key.
The short DHE keys I have seen have usually been 512 bits, but I have
seen servers sending keys as short as 256 bits.
I have seen these keys on both normal webservers and mail servers, but I
have an impression that there are more reports about the mail servers.
I think it might be an idea for TLS specification to include
recommendations about how such keys should be selected.
My preference for such a recommendation is that the ephermal key should
be as long, or as strong, as the key used to sign the ephermal key. I
don't think the specification should mention specific keylengths,
because what is secure is likely to change over time.
Comments?
[this is the important part:]
As far as Opera is concerned, I am considering a few options, including
automatically disabling the ephermal ciphersuites or re-sorting the
cipher suite list toplace them last, and renegotiate the connection.
[Apparently my memory was incorrect and the session was
renegotiated instead of the close->reconnect->negotiate
sequence I stated; however, support for renegotiation is
optional, so it may not always work.]
The folks at Opera Software have expressed how difficult
it was to secure their browser, and how insecure some
servers are (256-bit DH parameters!).
Yes that's interesting but irrelevant. Those are pretty
clearly mistakes on the server side, as are RSA e values
of 1. Neither is likely to be fixed by specifying security
levels in the way you suggest.
This proves my point -- lots of application developers and/
or server operators don't understand this stuff to the level
required to make all the right choices.
Another issue I've been meaning to bring up is that
if you want forward secrecy, you need to use Diffie-
Hellman; however, there is no way to tell the server
the size of the parameter p you want. Increasing the
size of p has significant performance implications,
so servers will typically use 1024 bits.
[...] It would be better if those
who want to use 4096 bits could ask for it.
Again, please present some evidence that this is a real
practical issue outside of a very small population of
keylength fetishists.
RSA key exchange provides up to 368 bits of security, but
doesn't provide forward secrecy. If I want forward secrecy,
then I need to use Diffie-Hellman. A server that has 1024-
bit Diffie-Hellman parameters only provides me with some-
where in the neighborhood of 70-80 bits of security
(extrapolated from the data in RFC 3526). You are saying
that I am a "keylength fetishist" because I want better
than 70-80 bits of security? So I'm allowed either lots
of "strength" *or* forward secrecy, but not both? That's
irresponsible.
Mike
_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls
RSA key exchange provides up to 368 bits of security, but
doesn't provide forward secrecy. If I want forward secrecy,
then I need to use Diffie-Hellman. A server that has 1024-
bit Diffie-Hellman parameters only provides me with some-
where in the neighborhood of 70-80 bits of security
(extrapolated from the data in RFC 3526). You are saying
that I am a "keylength fetishist" because I want better
than 70-80 bits of security? So I'm allowed either lots
of "strength" *or* forward secrecy, but not both? That's
irresponsible.
Mike
_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
