Re: [TLS] security levels for TLS

"Yngve Nysaeter Pettersen" <yngve@opera.com> Mon, 08 October 2007 18:43 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IexZK-00043T-JD; Mon, 08 Oct 2007 14:43:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IexZJ-00043J-Mx for tls@lists.ietf.org; Mon, 08 Oct 2007 14:43:05 -0400
Received: from mail.opera.com ([213.236.208.66] helo=mailbox.opera.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IexZD-0000TD-Bg for tls@lists.ietf.org; Mon, 08 Oct 2007 14:43:05 -0400
Received: from killashandra-ii.oslo.opera.com (pat-tdc.opera.com [213.236.208.22]) by mailbox.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l98IgcBM002631; Mon, 8 Oct 2007 18:42:38 GMT
Date: Mon, 08 Oct 2007 20:42:09 +0200
To: "Nikos Mavrogiannopoulos" <nmav@gnutls.org>, tls@lists.ietf.org
Subject: Re: [TLS] security levels for TLS
From: "Yngve Nysaeter Pettersen" <yngve@opera.com>
Organization: Opera Software
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
MIME-Version: 1.0
References: <c331d99a0710080621g7c0ec91et35c46553c23f4402@mail.gmail.com>
Content-Transfer-Encoding: 7bit
Message-ID: <op.tzv58jqzvqd7e2@killashandra-ii.oslo.opera.com>
In-Reply-To: <c331d99a0710080621g7c0ec91et35c46553c23f4402@mail.gmail.com>
User-Agent: Opera Mail/9.21 (Win32)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc:
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: yngve@opera.com
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@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

On Mon, 08 Oct 2007 15:21:42 +0200, Nikos Mavrogiannopoulos  
<nmav@gnutls.org> wrote:

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

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: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls