Subject: [TLS] security levels for TLS

From: "Nikos Mavrogiannopoulos" <[email-masked]>
Date: Mon, 8 Oct 2007 16:21:42 +0300

Hello,
 It seems that in TLS the security level of a connection relies on
several factors including the ciphersuite. In certificate
authentication the certificate plays also a large factor in the
security, and especially the public key of it, plus the signer's
public key.

This is not visible and neither understandable in everyday work with
TLS by typical users. For example a browser connection to a site with
a 512 bit RSA key that negotiated an 128 bit ciphersuite will not
differ to a connection with a 2048 bit RSA key and the same
ciphersuite, with regard to visible user data. This makes difficult
for users to judge the security level of the connection and one must
never assume that a user would understand what a 512 bit RSA key
means.

For this reason I think using some form of uniform security levels to
indicated TLS security would be useful in end-applications. Those
levels could be defined in steps (as in [0]), based on objective
information of the key sizes in the certificates, the DHE prime and
generator sizes (if applicable), the MAC output size of the
ciphersuite as well as the key size of the cipher.

Then the security level could be printed either as a number (70 bits
of security) or as "weak, low, medium, high" based on some definitions
of these terms... I could make it more detailed if there is some
interest. What do you think?

regards,
Nikos

[0]. "Practical Cryptography", Fergunson, Schneier

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 08 Oct 2007 08:32:18 -0700

At Mon, 8 Oct 2007 16:21:42 +0300,
> interest. What do you think?

I think this is something that the TLS WG should avoid getting involved
in.

1. It's not really possible to come up with a single figure of merit
   in an uncontroversial way. To take the simplest possible case, what
   security level should we assign to TLS_RSA_WITH_NULL_SHA1 when the
   key is 1024 bits? What's the security level of TLS_RSA_DHE_* 
   when the RSA key is 1024 bits and the DH key is 512? How about
   the other way around? 
2. These numbers change over time as attacks get better. Unfortunately,
   those changes aren't straightforward. For instance, it's not
   really that easy to assess the security of HMAC-MD5 right now,
   especially if the question you're interested in asking is how
   secure it will be in a year (and the horizon you'd need to be
   thinking about is more like 5 years).
3. It seems likely that once you get past a fairly modest algorithm
   strength (40 bits? 64 bits?) the dominant security predictor
   about a given system is implementation quality (remotely exploitable
   vulns, RNG quality, ...), not algorithm strength. I don't know how
   to assess that.
   
-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 8 Oct 2007 19:14:28 +0300

> I think this is something that the TLS WG should avoid getting involved
I do agree that there is a lot of complexity in this issue, but the TLS WG is 
the only WG that could do this at least for TLS.

>    when the RSA key is 1024 bits and the DH key is 512? How about

This cannot be 100% objective by definition, but it can be based on a rational 
process. Of course the security level of those cryptosystems should be 
calculated using the weakest of the used algorithms.

I've thought about that while reading "Selecting cryptographic key sizes" 
(available at http://www.win.tue.nl/~klenstra/key.pdf)
Which gives an answer to your questions above. 

>    thinking about is more like 5 years).

I'm not talking about assessing individual algorithms, but rather give an 
estimation of security based on objective facts as the key size etc. Of 
course one cannot give precise security levels. 

>    vulns, RNG quality, ...), not algorithm strength. I don't know how

Indeed, but having at least an estimation of security based on some objective 
factor I think it is a good step forward. 

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 08 Oct 2007 09:22:07 -0700

At Mon, 8 Oct 2007 19:14:28 +0300,
Nikos Mavrogiannopoulos wrote:
> I do agree that there is a lot of complexity in this issue, but the
> TLS WG is the only WG that could do this at least for TLS.

Yes, but just because we are the only ones who could do it does
not mean that we should?

> calculated using the weakest of the used algorithms.

So, the security level of null encryption is 0 because the weakest
algorithm (the confidentiality algorithm) has a zero-length key?
If that's so, what's the security level of an X.509 certificate signed with
a 1024-bit RSA key. That doesn't offer any confidentiality either.

> Which gives an answer to your questions above. 

I'm familiar with this work. It does not answer my questions above,
and the reason it does not is that they are questions that depend
critically on the operational environment and the threat model.
Cryptosecurity is about a lot more than key size.

> course one cannot give precise security levels. 

So, HMAC-CRC with a key size of 1000 bits would have what security
level in this scheme?

> factor I think it is a good step forward. 

I don't. When most of the variance is in some other factor, then
measuring security of whatever factor you happen to be able to
measure is extremely misleading.

-Ekr

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Mon, 08 Oct 2007 20:42:09 +0200

> interest. What do you think?

Opera has been using a multi-level security indicator since we implemented  
SSL, the value of which is determined by input such as the symmetric  
keylengths, the public keys used in the certificate chain and the key  
exchange, OCSP results, certificate warnings, etc. We also display  
warnings if the strength of a method is less than we consider reasonably  
secure (at the moment, in 9.5 alpha, the limit for RSA/DH(E)/DSA is 900  
bits, but this can be increased in 100 bit steps by a preference).

Our position is that the weakest method defines the strength of a  
connection and a document, which for example means that we consider a  
AES-256 connection weak if one of the certificates use a 512 bit RSA key,  
or if a 2048 bit RSA key is used to secure a 56 bit DES connection.

The W3C Web Security Context (WSC) Working Group is presently considering  
at least one proposal [1] for how an improved security indicator can be  
defined, as well as numerous other issues in the area.

For more informations please see:

Opera's system:

   <URL:  
http://lists.w3.org/Archives/Public/public-wsc-wg/2006Nov/0036.html >
   (related) <URL:  
http://my.opera.com/yngve/blog/2007/06/19/it-aint-ev-til-its-ev-all-ev >

W3C WSC WG:

   <URL: http://www.w3.org/2006/WSC/ >
   [1] <URL:  
http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals/PageScore >

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		                 Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Oct 2007 18:29:33 -0400

Ekr's right: this is not a tractable problem. We could certainly come 
up with some numbers, but they would be meaningless (and therefore 
dangerous) with so much context that we might as well have just given 
the context by itself.

The fact that the W3C wants to wade into this swamp should not lead 
us there, other than to maybe offer them a rope back to the shore 
where they started.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 10 Oct 2007 09:09:22 -0400

NIST has taken the "build it and they will come" approach to
projecting a multi-dimensional security space down to a few
coarse-granularity levels in
http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf.

There is merit in what W3C is attempting to do, but it's
questionable whether a consensus process with no benevolent
dictator can pull it off.  And the more quantization levels
one attempts to define in a security metric, the more difficult
the problem becomes.  If W3C took the SP800-63 approach and
tried to characterize just 3 or 4 levels (good/better/best,
red/yellow/green, Harvey balls, etc), they would have a chance
at producing something that would be truly useful for policy-driven
access enforcement.  Human enforcement, of course, is a lost
cause - how many people even look at the padlock in the first
place, much less would make distinctions based on its color?

Dave

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2007 6:30 PM
To: Nikos Mavrogiannopoulos; [email-masked]
Subject: Re: [TLS] security levels for TLS

--Paul Hoffman, Director
--VPN Consortium

---

From: Mike <[email-masked]>
Date: Wed, 10 Oct 2007 09:48:03 -0700

There are two aspects to this that I see:

   1) a TLS client should be configurable such
      that it will reject negotiated sessions
      that don't satisfy its requirements.  The
      configurable parameters would include the
      minimum acceptable size for RSA and DSA
      keys, and DH parameters (p).  This can be
      done now without any changes to TLS, but
      has the problem that several attempts may
      be necessary to establish an acceptable
      connection.

   2) a TLS client might want to tell the server
      that if TLS_DHE_RSA_WITH_AES_128_CBC_SHA1
      is the negotiated cipher, it will accept
      a minimum RSA key size of X and a minimum
      DH parameter size of Y.  If the server
      has several sets of DH parameters (such as
      those in RFC 3526), it would select one
      that meets the minimum and is smallest for
      best performance.  If the server doesn't
      have the ability to satisfy the minimums,
      it could return an insufficient_security
      fatal alert.

Support for (2) could be added using an extension:

   enum {
       RSA,
       DHE_RSA,
       DHE_DSS,
       ...
   } KeyExchangeAlgorithm;

   struct {
       CipherSuite         cipher_suite;
       HashType            mac_algorithm<0..255>; // possible
       select (KeyExchangeAlgorithm) {
           case RSA:
               uint16      rsa_key_size;          // bytes
               uint16      premaster_secret_size; // possible
           case DHE_RSA:
               uint16      rsa_key_size;          // bytes
               uint16      dh_group_size;         // bytes
           case DHE_DSS:
               uint16      dsa_key_size;          // bytes
               uint16      dh_group_size;         // bytes
           case ....
       };
   } SecurityRequirements;

The client would package up SecurityRequirements
structures for each of the cipher suites listed in
its ClientHello message.

Notice the possibility to change the MAC algorithm
without needing to define new cipher suites.  A list
is used to be able to specify preferences (and can be
empty for AEAD ciphers).

The server would return a single SecurityRequirements
corresponding to the selected cipher suite, containing
the parameters chosen (MAC algorithm, premaster secret
size, etc.).

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 Oct 2007 11:03:23 -0700

At Wed, 10 Oct 2007 09:48:03 -0700,
>       be necessary to establish an acceptable

This seems like a perfectly reasonable capability for
a developer to provide, I'm not convinced that a
developer *should* provide it. In any case, it's
not an IETF issue.

>       it could return an insufficient_security

This adds significant complexity for what's in my experience,
a non-problem. The vast majority of servers I am familiar with
have one and only one set of asymmetric keying material, so
selecting it isn't a problem. Moreover, it's simply not the
case that one can express the security of an algorithm
purely in terms of the number of bits of claimed keying
material. Examples include 3DES (112 or 168?, depends on
the attack), EC (it's not clear that all groups of the same
size are equally secure).

Absent some significant evidence that this is a problem in 
practice, I'm against the TLS WG doing anything along these
lines.

-Ekr

---

From: Mike <[email-masked]>
Date: Thu, 11 Oct 2007 08:39:05 -0700

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);

and know that the resulting connection will either meet
the (implementation-dependent) criteria for that level of
security, or the TLS negotiation will fail?

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

This is inefficient and error-prone, and makes it much
harder to know how secure your IT infrastructure as a
whole is since there are as many points of failure as
there are applications.  Also as attacks improve and the
security requirements change, every application needs to
be reexamined and modified.

It would be much better if all that was needed was to
replace the TLS library with an updated version.  Or
better yet, the TLS library may have a plain text
configuration file for its security levels that could
be replaced, and all you need to do is restart your
applications.

> practice, I'm against the TLS WG doing anything along these

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!).  The W3C is also
attempting to solve this problem, but the need extends
beyond HTTPS.

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.  On my Windows
machine, it takes 0.02 seconds to generate a public key
and another 0.02 seconds to compute the secret using
1024-bit parameters.  Moving to 2048-bit parameters,
the computation time increases to 0.15 seconds each.
4096-bit computations take 1.1 seconds.  No server
operator will decrease throughput by a factor of 50
for everyone, just to accommodate the few who want
this level of security.  It would be better if those
who want to use 4096 bits could ask for it.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Oct 2007 08:58:27 -0700

At Thu, 11 Oct 2007 08:39:05 -0700,
>      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.

>        some cipher suites from the acceptable list and

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.

> be replaced, and all you need to do is restart your

And again, this is an API/local isssue. IETF doesn't do
those.

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

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

-Ekr

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Oct 2007 11:21:53 -0500

> not expressible via a single metric, making this a complete rathole.

Agreed.  SASL used to have a notion of "security strength factor" (SSF),
and that was a disaster.

You cannot calculate an _absolute_ and _objective_ measure of security
for anything, least of all cryptographic algorithms subject to future
cryptanalytic advances (i.e., all of them).  (Don't even mention future
quantum computers.)

Basically, the best you could do is have an application choose a
cryptographic profile by descriptive names like "strong" and "fast," but
where the content of such profiles is subject to change over time, and
perhaps even a local matter.  Today "strong" might mean AES-128 is OK,
and tomorrow it might mean only AES-256 is OK, and the next day it might
mean something else, and so on.

> I appreciate it's a potential problem *in theory* but that's

The easy answer is to give the application fewer choices, namely a
choice of locally-configured profiles (see above).

In fact, I strongly urge TLS API developers to provide such a facility.

> And again, this is an API/local isssue. IETF doesn't do

There you go again.  The IETF most certainly deals in APIs.  Though in
this case I think the IETF need not have any specifications requiring or
recommending a facility like I describe above.  If it helps ward off
requests for silly things like "security strength factors" and those are
common enough, then perhaps we should indeed have an information RFC
explaining why we can't and what developers can do instead.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Oct 2007 09:23:11 -0700

At Thu, 11 Oct 2007 11:21:53 -0500,
Nicolas Williams wrote:
> There you go again.  The IETF most certainly deals in APIs.

Let me rephrase: the IETF generally doesn't deal in APIs with a few
prominent exceptions. The TLS-WG has never done so and I don't think
it's a good idea to do so now.

-Ekr

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 11 Oct 2007 18:26:27 +0000

On Thu, 11 Oct 2007 09:23:11 -0700

> it's a good idea to do so now.
And certainly not where the goal is this dubious.  I'm with ekr: this
is a bad idea.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Oct 2007 13:33:16 -0500

> And certainly not where the goal is this dubious.  I'm with ekr: this

To clarify, I agree as well.  We already know from experience with SASL
that this is a bad idea.

---

From: Mike <[email-masked]>
Date: Thu, 11 Oct 2007 21:26:19 -0700

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

> 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 woFrom [email-masked] Fri Oct 12 00:28:29 2007
Date: Thu, 11 Oct 2007 21:26:19 -0700
From: Mike <[email-masked]>
To: [email-masked]
Subject: 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.]

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

> I appreciate it's a potential problem *in theory* but that's

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

> levels in the way you suggest.

This proves my point -- lots of application developers anduld 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.)

> I appreciate it's a potential problem *in theory* but that's

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

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

>> so servers will typically use 1024 bits.
>> [...] It would be better if those

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

---

From: Mike <[email-masked]>
Date: Thu, 11 Oct 2007 21:32:28 -0700

> In fact, I strongly urge TLS API developers to provide such a facility.

I'm confused -- that is exactly what TLS::SetSecurityLevel (3);
was intended to represent.  Perhaps if I had not used the number
3, but instead used SECURITY_LEVEL_STRONG this would have made
more sense to people?

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Oct 2007 21:57:17 -0700

At Thu, 11 Oct 2007 21:26:19 -0700,
Mike wrote:
> even allow it at level 1.

Well, I consider 168 bits a lot more accurate under most
threat models--which is of course the point. As for "level 1",
I don't even understand what you're saying here. 3DES is
plenty secure for any known application. The difference between
112 and 168 is basically insignificant for any practical 
application. The existence (or nonexistence) of known (or unknown)
analytic attacks is much more important.

>  I have to admit I don't know the

No, it's not clear that it's known, actually. As another example,
how do you compare 1024 bits with PFS to 1024 bits without?

> chance?

Arguably, it would have been, but it's not the way that the
system is now, and I haven't seen an argument that this
needs to change..

> provide a security expert full control of course.)

You should feel free to do this in your implementation. I'm only
objecting to TLS-WG being involved.

[Yngve's report of extremely weak DH keys deleted].
> optional, so it may not always work.]

Yes, yes, I know about all this. But as I said, use of a 256-bit 
DH group (and probably 512-bit) is a clear implementation error.

> required to make all the right choices.

Yes, I agree that they don't but it's not clear to me why
you think that having the client express its opinion improves
the situation, given that the problem is that the server is
misconfigured. 

> doesn't provide forward secrecy. 

As does DH with appropriate key sizes. RSA and DH have approximately
equivalent strengths with the same modulus size. 

> If I want forward secrecy,

Nobody is stopping you from using any DH key size you want with 
TLS (or RSA, for that matter.) It's just that the server controls
the key size with no input from the client. I have yet to see
any evidence that there's substantial demand from clients for
input on the key size. That said, if you really care, you can
use ECC, which *does* permit the client to advertise the groups
it wants.

-Ekr

---

From: Mike <[email-masked]>
Date: Fri, 12 Oct 2007 10:55:49 -0700

> system is now....

I thought of an easier way to achieve this that should be less
controversial and simple to implement.  As an extension, it
would be completely optional as well, but I believe it would
be widely implemented:

     enum {
         diffie_hellman_parameter (0),
         server_rsa_key           (1),
         ca_rsa_key               (2),
         server_dsa_key           (3),
         ca_dsa_key               (4),
         ....
         (65535)
     } KeyType;

     struct {
         KeyType    key_type;
         uint24     preferred_size;
     } PreferredKeySize;

     struct {
         PreferredKeySize sizes<0..2^16-1>;
     } PreferredKeySizeExtension;

A server that understands this extension would reply with an
empty extension_data.  The server would do its best to select
keys, certificate chains, and DH parameters to satisfy the
client's request.  If it is unable or unwilling to do so, the
negotiation should proceed giving the client the opportunity
to accept weaker parameters than it asked for.  (Or a boolean
value could be added to the extension indicating whether the
client might accept weaker parameters; if not, the server
could immediately send a fatal insufficient_security alert.)

 > and I haven't seen an argument that this
 > needs to change..

The server's response would let the client know that it would
be a waste of time to try negotiating again with different
cipher suites if it found the key lengths to be unacceptable.
Clients and servers would spend less time performing fruitless
renegotiations, which would reduce server throughput.  This
seems like a good argument to me.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 12 Oct 2007 11:04:44 -0700

At Fri, 12 Oct 2007 10:55:49 -0700,
> seems like a good argument to me.

Yes, but it's unconvincing to me for reasons I've already stated.
When I start to hear stories about repeated client reconnect
probes due to key size mismatches *for reasons other than obvious
server config errors*, I'll get interested in this.

-Ekr

---

From: Mike <[email-masked]>
Date: Fri, 12 Oct 2007 12:04:14 -0700

> server config errors*, I'll get interested in this.

Apparently no argument will suffice, and you would rather keep the
status quo than be proactive.  How long do you think it would take
to add this extension to a TLS toolkit?  In my own code, I could
probably do it in less than a day, with time left over to get in a
round of 18 holes.

Mike

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 12 Oct 2007 15:26:26 -0400

>probably do it in less than a day, with time left over to get in a

No doubt. Of what positive and negative value would such code be? 
Confusing and/or giving users false senses of security are definitely 
negative.

--Paul Hoffman, Director
--VPN Consortium

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 12 Oct 2007 22:37:30 +0300

> Confusing and/or giving users false senses of security are definitely

Actually I think the latter sentence describes the current situation!

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 12 Oct 2007 13:00:32 -0700

At Fri, 12 Oct 2007 22:37:30 +0300,
> Actually I think the latter sentence describes the current situation!

How so? Nothing at all stops you from putting any indicator you
like in your code. Why does IETF have to standardize it?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 12 Oct 2007 12:59:51 -0700

At Fri, 12 Oct 2007 12:04:14 -0700,
Mike wrote:
> status quo than be proactive. 

Say rather that I would rather not make unnecessary modifications
to a stable standard.

As for the claim that "no argument will suffice", the message you
replied to pretty clearly spelled out what would suffice, so
I'll take this message as meaning that you don't have any 
real evidence along these lines.

> How long do you think it would take
> to add this extension to a TLS toolkit? 

This does not seem to me to be a relevant consideration.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 12 Oct 2007 13:00:32 -0700

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 12 Oct 2007 12:59:51 -0700

-Ekr

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 12 Oct 2007 15:15:35 -0500

> 3, but instead used SECURITY_LEVEL_STRONG this would have made

It's not what was requested early on in this thread.  Local, named
profiles -> good.  Standard profiles with absolute security ratings
associated with them -> super bad.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 12 Oct 2007 15:23:32 -0500

> probably do it in less than a day, with time left over to get in a

That's not a helpful argument.

I suggest you go look at SASL's SSF concept and why noone cares for it.
There's lots of mailing list archive material to wade through!

Nico
--

---

From: Mike <[email-masked]>
Date: Fri, 12 Oct 2007 14:41:51 -0700

> No doubt. Of what positive and negative value would such code be?

Positives:

   - this would allow a server to maintain multiple sets of keys
     and certificate chains of varying cryptographic strength;
     clients with differing requirements could ask for the level
     they desire, instead of being stuck with the lowest common
     denominator
   - a server could support multiple sets of Diffie-Hellman
     parameters, such as all of the groups in RFC 3526; a client
     could choose the parameters rather than being forced to
     accept the server's default (which is probably chosen more
     for performance than security)
   - knowing exactly what the client is looking for helps the
     server select the appropriate cipher suite without the need
     for the client to renegotiate the connection; for example,
     if the server only supports 1024-bit DH parameters, and the
     client asks for 1536-bit, the server can skip past the DHE_*
     cipher suites and select maybe an RSA-based cipher suite
     that the client would accept
   - this mechanism would give power to the client that it
     currently doesn't have, to directly influence the crypto-
     graphic strength of the connection beyond simply listing
     acceptable cipher suites
   - hash agility (or now signature algorithm agility) is being
     added to TLS; this is cryptographic strength agility
   - a client is free to develop its own security profiles; no
     "standard" profiles would be defined
   - a server can keep statistics on the values it receives,
     allowing an administrator to know when it would make sense
     to add support for longer keys, based on actual demand

Negatives:

   - effort is needed to write a specification and approve it
   - a server may not support the extension, so a client may
     have to implement an inefficient renegotiation scheme in
     addition anyway
   - Eric doesn't like it ;-)
   - Others?

> Confusing and/or giving users false senses of security are definitely 

Fully agreed.  I don't see how this would be confusing or give
a false sense of security.  The client still has to check that
the requested key lengths (and other parameters it cares about)
are satisfied in the negotiated session.

Mike

---

From: Mike <[email-masked]>
Date: Fri, 12 Oct 2007 14:58:19 -0700

> real evidence along these lines.

That comment was made out of frustration, and I apologize for it.

> This does not seem to me to be a relevant consideration.

I just responded to Paul with a list of a half dozen benefits
of adding this extension.  If you agree that the benefits are of
value, then the fact that it's easy to implement is a bonus.

Mike

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 12 Oct 2007 16:59:01 -0500

>     they desire, instead of being stuck with the lowest common

It can do things like this today.

>     that the client would accept

The server and client already know how to negotiate properly.

>     graphic strength of the connection beyond simply listing

The client already can negotiate from what it's willing to accept, and
that's sufficient.

>     added to TLS; this is cryptographic strength agility

You're ignoring everything we've been telling you about why absolute
security measurements of ciphersuites are not a good idea.

>     "standard" profiles would be defined

The client and server are already free to do so.

>     to add support for longer keys, based on actual demand

The server can already do this.

>   - Eric doesn't like it ;-)

This is not about personal preferences.  We're telling you this is not
needed and that fixed absolute cryptographic strength numbers are
neither feasible nor a good idea.

> are satisfied in the negotiated session.

Eric points out that local policy is sufficient to achieve what you
want.  I do think that a standard way to describe security policies for
TLS and other protocols might be useful for distributing policy, but at
the end of the day that'd still be _local_ policy, with no changes to
TLS being required.

Nico
--

---

From: Mike <[email-masked]>
Date: Fri, 12 Oct 2007 16:15:22 -0700

> like in your code. Why does IETF have to standardize it?

I think there is some mis-communication going on.  I have never
even mentioned the IETF standardizing an "indicator" of security
level.  Someone else may have, but I reject that idea as well.

All I've proposed is that the client send a few extra bytes of
information specifying the sizes of keys/parameters that are
not defined by the cipher suites.  Every client is free to
determine what it thinks is acceptable in this regard.  There
would be no "standard profiles" or even "suggested profiles"
since over time they would become outdated.

Here is a simple code example of what I envision:

    TlsSecurityProfile profile_Generic;
    TlsSecurityProfile profile_Strong;

    profile_Generic.SetRSAKeyLength (1024, 900);  // desired, minimum
    profile_Generic.SetDSAKeyLength (1024, 900);
    profile_Generic.SetDHParameterSize (1024, 1000);

    profile_Strong.SetRSAKeyLength (2048, 2000);
    profile_Strong.SetDSAKeyLength (2048, 2000);
    profile_Strong.SetDHParameterSize (1536, 1536);

    ConnectTLS ("www.amazon.com:443", profile_Generic);
    ConnectTLS ("www.mybank.com:443", profile_Strong);

Currently TLS cannot totally support this interface, but with the
extension I proposed, it could.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 12 Oct 2007 15:00:36 -0700

At Fri, 12 Oct 2007 14:41:51 -0700,
>      for performance than security)

Note that the server can already maintain multiple keys and choose one
based on the cipher suite. It's merely that the client can't *directly*
request specific asymmetric key sizes for DH and RSA.

>      have to implement an inefficient renegotiation scheme in

- It encourages an inappropriate focus on key size. As I said already,
  There's a lot more to security than key size. 
- It adds yet more unnecessary complexity to a spec which is already
  quite complicated. 
- It's yet another way to have interop problems.
- Implementations which want DH key sizes significantly greater than
  1024 would be better served to move to EC, which already has
  explicit support for communicating which groups are supported.

>    - Eric doesn't like it ;-)

I don't see you getting a lot of support from others, either.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 12 Oct 2007 17:00:10 -0700

At Fri, 12 Oct 2007 16:15:22 -0700,
> level.  Someone else may have, but I reject that idea as well.

Well, two things seem to be being discussed simultaneously:

1. Standardizing simplified "levels" of security which correspond to 
   cipher suites and key sizes.

   E.g., STRONG would be symmetric algorithm X or Y with asymmetric
	 algorithm A and key size a or asymmetric algorithm B with
	 key size b.
     
	 MEDIUM is symmetric algorithm W with asymmetric algorithm
	 A with key size a' or asymmetric algorithm B with key size
	 b'.
 
    This is purely a documentation issue and doesn't require any
    on-the-wire changes to TLS. 

2. Modifying TLS to allow the client to indicate the size of the
   keys/group it would like for each asymmetric algorithm. This
   is an on-the-wire protocol change. 

As I understand your messages, you've been endorsing both of these.

I'm against both of these, for related, but distinct reasons.

I'm against the former because I think it's actually very hard to
produce any reasonable standardized account of which algorithms and
key sizes fit into which level. In any case, this is something that an
implementation can easily offer without any standard, it simply will
not necessarily have the same level->algorithm mapping as another
implementation.

I'm against the second because I believe it adds marginal benefit
at a significant cost to interoperability and complexity. An 
extension like this only makes sense if:

1. Servers have a number of different kinds of keying material
   of different strengths.
2. Clients are in a position to make intelligent choices about
   which asymmetric key strengths are appropriate.

In my experience, neither is true. Moreover, it's worth noting
that in the current environment any client which attempts to
request a key > 1024 bits will find that it can connect to
practically nobody. To a first order, this is just another
way to create interop problems. 

With regard to key lengths: as I indicated before, the dominant
security issue in systems of this kind is quality of implementation
and maintenance. If you don't trust the server to choose appropriate
key sizes, why on earth would you trust that it's not chock full
of remote vulnerabilities?

-Ekr

---

From: Mike <[email-masked]>
Date: Fri, 12 Oct 2007 17:18:45 -0700

> It can do things like this today.

How?  The ClientHello only has a list of cipher suites to go by,
and they don't specify the sizes of the asymmetric keys.

[You removed the benefit of being able to specify the size of DH
parameters, so I'll assume you know you can't currently do that
today.  That alone is worth adding this extension, in my opinion.]

> The server and client already know how to negotiate properly.

No, they don't.  If a server sees a DHE_* cipher suite in the
ClientHello, but doesn't know that the client wants 1536-bit
(or larger) parameters, it may select it, even though it only
has 1024-bit parameters.  The client would have to renegotiate
the session without including the DHE cipher suites, which is
an avoidable waste of computing resources.

> The client already can negotiate from what it's willing to accept, and

Instead of "sufficient" I would say it is "tolerable, but lacking."

> security measurements of ciphersuites are not a good idea.

I've never said anything about absolute security measurements.
Why are all the security experts against specifying the relevant
parameters?  Why is it wrong for a TLS client to tell the server
that it wants to use 2048-bit RSA keys?

> The client and server are already free to do so.

Right, but if the profile says, "accept 2048-bit RSA keys,"
there is no way for the client to tell the server that that is
what it wants.

> The server can already do this.

How can it do that if this extension doesn't even exist?

> This is not about personal preferences.

That's why I put a wink after it.

> We're telling you this is not

Again with the "fixed absolute cryptographic strength numbers."
I have never said anything about that.

Need is a crazy thing.  Nobody needed a camera in their cell
phone just a few years ago, but it's now hard to find one
without a camera (in the U.S. at least).

Mike

---

From: Mike <[email-masked]>
Date: Fri, 12 Oct 2007 17:42:22 -0700

> request specific asymmetric key sizes for DH and RSA.

I'm proposing an extremely simple way to let the client directly
request the desired key sizes.  Isn't that better than hoping that
the server replies with an acceptable key?

>   There's a lot more to security than key size.

But key size -is- a big part of it, and you should be able to tell
a server what key sizes you want, rather than leave it up to chance.

Let me express this in a different way:

Imagine if TLS already had the ability for a client to specify key
sizes to the server, and I was arguing to get rid of that.  Wouldn't
you think I was crazy for suggesting it?

> - It adds yet more unnecessary complexity to a spec which is already

I'm aware of how complicated it is.  I'm in the process of trying
to add support for some of the existing extensions such as the
trusted CA indication, and the complexity of that is so much more.

> - It's yet another way to have interop problems.

Isn't every addition?

>   explicit support for communicating which groups are supported.

And pay someone for the right to generate a self-signed certificate?
If you can do it with EC, why do you argue against doing it for DHE?

> I don't see you getting a lot of support from others, either.

I find myself in this position occasionally, and accept that most
people will stay out of the line of fire.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 12 Oct 2007 17:37:37 -0700

At Fri, 12 Oct 2007 17:18:45 -0700,
> an avoidable waste of computing resources.

Look, this scenario is basically bogus now, and I suspect
in the future.

Nearly all servers have 1024-bit RSA keys signed by 1024-bit
RSA CA keys. If they have DHE, then that's 1024-bit too.
If the client wants 1536-bit anything, it's SOL, and neither
asking for it in its ClientHello nor dropping DHE from its
cipher suites and reconnecting will help. And even if the
server *did* have multiple DHE groups, why would it be
OK from the client's perspective to have those authenticated
with a long-term 1024-bit RSA key? That's part of what 
people have been trying to tell you about absolute security
levels.

Now, one could certainly argue that in the future servers
may have a variety of ephemeral DH parameters, but they're
going to in general want to use the weakest one that's
acceptable to them. Either this extension is mandatory
to comply with (like ECC groups), in which case the client
basically can't set it above 1024 or he won't be able to
talk to most servers, or it's optional, in which case
I would expect servers to ignore it, since it will reduce
their performance and if they wanted stronger keys they
would just use them.

-Ekr

---

From: Mike <[email-masked]>
Date: Fri, 12 Oct 2007 18:14:38 -0700

> As I understand your messages, you've been endorsing both of these.

I said above that I reject the idea of standardizing levels.  Why
don't you believe that?  You must be attributing someone else's
statements with me.

> not necessarily have the same level->algorithm mapping as another

I said in one of my first messages that this would be implementation
dependent.

> way to create interop problems. 

Well if you implement TLS 1.1 and expect to connect to anyone,
you will be disappointed, and yet we're working even on TLS 1.2.
There is always a transition period with new capabilities.

> of remote vulnerabilities?

Perhaps the server has different goals than you do -- it might
want to maximize transactions.  But maybe it would let you select
better security if you asked for it.  Currently there is no way
to ask.

Mike

---

From: Mike <[email-masked]>
Date: Fri, 12 Oct 2007 18:34:24 -0700

>> If a server sees a DHE_* cipher suite in the

Right, and I want to fix that.

> people have been trying to tell you about absolute security

Everyone uses 1024-bits because everyone else uses 1024-bits,
and they feel a sense of security in numbers.  In other words
they can't be fired if something goes wrong because the whole
industry does it.

> their performance and if they wanted stronger keys they

As we've both noted there are performance/security tradeoffs,
and I believe the client is in a better position to decide
what level of security is desired for any given transaction.
The server doesn't know what operations the client is going
to be requesting until after TLS is negotiated.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 13 Oct 2007 00:22:10 -0700

At Fri, 12 Oct 2007 18:14:38 -0700,
Mike wrote:
> don't you believe that? 

Maybe because your writing has been fairly unclear. I read the following
as such an endorsement:

If you say it's not, I believe you.

> I said in one of my first messages that this would be implementation

That wasn't clear to me, but fine.

> you will be disappointed, and yet we're working even on TLS 1.2.

Yes, because it was felt that the attacks on MD5 and SHA-1 
created an important need. Prior to those attacks, I had
every intention of taking TLS 1.1 to draft standard without
change.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 13 Oct 2007 00:18:47 -0700

At Fri, 12 Oct 2007 17:42:22 -0700,
> a server what key sizes you want, rather than leave it up to chance.

Yes, you keep saying that, but you haven't convinced me.

> you think I was crazy for suggesting it?

Yes, because it would be an unnecessary change, exactly like
the one you propose is. We're not designing in a vacuum, we've
got an existing protocol that works well. That means that
every proposed change requires justification. I don't think
you've met that bar.

> > - It's yet another way to have interop problems.

Yes. Which is why every addition needs to be justified.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 13 Oct 2007 00:36:13 -0700

> a server what key sizes you want, rather than leave it up to chance.

To sharpen the point I was trying to make earlier, once you're using
keys in the 1024-bit range, there are actually a number of other
factors which are of equivalent if not larger importance to key
size. These include:

- The quality of PRNG used to generate the key.
- Whether the key is being securely stored (e.g, in an HSM).
- When we're talking DH, whether each ephemeral is fresh, and
  the structure of the DH group.
- Which server is in use.
- Whether the server software is up to date.

The last two in particular are of vastly more importance than key
size. I have never heard of a 1024-bit RSA key being cracked, yet I'm
aware of remote vulnerabilities in every major C-based SSL
server. These vulnerabilities lead to far easier private key
extraction than factoring the modulus.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 13 Oct 2007 15:14:20 -0400

At 2:41 PM -0700 10/12/07, Mike wrote:
>>Confusing and/or giving users false senses of security are 
>>definitely negative.
>
>a false sense of security.

OK, that is a point where you seem to disagree with most others 
posting on this thread.

--Paul Hoffman, Director
--VPN Consortium