Re: [TLS] security levels for TLS

Eric Rescorla <ekr@networkresonance.com> Fri, 12 October 2007 23:59 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 1IgUPc-0001Jq-Dz; Fri, 12 Oct 2007 19:59:24 -0400
Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgUPb-0001Iw-1z for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 19:59:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgUPa-0001Ij-Oi for tls@lists.ietf.org; Fri, 12 Oct 2007 19:59:22 -0400
Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgUPU-0002RV-Ik for tls@lists.ietf.org; Fri, 12 Oct 2007 19:59:22 -0400
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id E3DFC33C21; Fri, 12 Oct 2007 15:00:36 -0700 (PDT)
Date: Fri, 12 Oct 2007 15:00:36 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Mike <mike-list@pobox.com>
Subject: Re: [TLS] security levels for TLS
In-Reply-To: <470FEA1F.7030500@pobox.com>
References: <c331d99a0710080621g7c0ec91et35c46553c23f4402@mail.gmail.com> <p0624082fc331b0ed0ecc@[192.168.1.100]> <FA998122A677CF4390C1E291BFCF59890849871E@EXCH.missi.ncsc.mil> <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> <20071012045718.DE16033C21@delta.rtfm.com> <470FB525.7010308@pobox.com> <20071012180445.1D22D33C21@delta.rtfm.com> <470FC52E.6080707@pobox.com> <p06240828c3357a914a76@[192.168.1.3]> <470FEA1F.7030500@pobox.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20071012220036.E3DFC33C21@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: tls@lists.ietf.org
X-BeenThere: tls@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@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

At Fri, 12 Oct 2007 14:41:51 -0700,
Mike wrote:
> 
> >> 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.
> > 
> > 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)

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.


> 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

- 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


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