Re: [TLS] Re: Cipher-suite specific extensions

Bodo Moeller <bmoeller@acm.org> Fri, 22 July 2005 20:00 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw3ha-0005Fo-C3; Fri, 22 Jul 2005 16:00:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw3hY-0005Fi-Rl for tls@megatron.ietf.org; Fri, 22 Jul 2005 16:00:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17810 for <tls@ietf.org>; Fri, 22 Jul 2005 16:00:54 -0400 (EDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de ([130.83.167.3] helo=mail.cdc.informatik.tu-darmstadt.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw4Bq-0004Zf-Nk for tls@ietf.org; Fri, 22 Jul 2005 16:32:16 -0400
Received: from cdc-ultra5.cdc.informatik.tu-darmstadt.de (cdc-ultra5 [130.83.167.9]) by mail.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 934FE2CBD; Fri, 22 Jul 2005 22:00:42 +0200 (MET DST)
Received: (from moeller@localhost) by cdc-ultra5.cdc.informatik.tu-darmstadt.de (8.11.7p1+Sun/8.11.7) id j6MK0fb10274; Fri, 22 Jul 2005 22:00:41 +0200 (MEST)
Date: Fri, 22 Jul 2005 22:00:41 +0200
From: Bodo Moeller <bmoeller@acm.org>
To: Simon Blake-Wilson <sblakewilson@bcisse.com>
Subject: Re: [TLS] Re: Cipher-suite specific extensions
Message-ID: <20050722220040.A10159@cdc.informatik.tu-darmstadt.de>
References: <87y87zhgvy.fsf@scholes.stanford.edu> <0c1c01c58ed9$8c2c5450$3200a8c0@simon>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <0c1c01c58ed9$8c2c5450$3200a8c0@simon>; from sblakewilson@bcisse.com on Fri, Jul 22, 2005 at 12:22:22PM -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: tls@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>
Sender: tls-bounces@lists.ietf.org
Errors-To: tls-bounces@lists.ietf.org

On Fri, Jul 22, 2005 at 12:22:22PM -0400, Simon Blake-Wilson wrote:

> I'm not aware of anything concrete beyond ECC curves and ECC point
> formats. I guess you could imagine something might be desired for things
> like RSA key sizes, especially if larger key sizes take off in conjunction
> with SHA-2.

The "trusted_ca_keys" extension is also a candidate for ciphersuite-
specific use -- if you only have the RSA key of some certification
authority, then you wouldn't want to announce this CA as trusted for
DSA ciphersuites as well.  However,

(i)  depending on how ciphersuite-specific extensions are approached,
     "trusted_ca_keys" as an existing extension cannot be retrofitted
     appropriately; and

(ii) in practice you'll get along quite well by circumenventing the
     problem: as long as CAs use different distinguished names for
     their different keys, nothing will go wrong.

Beyond this particular extension, it depends on how pluggable TLS
implementations are expected to be: Is this only about the key
exchange stage?  Or about the symmetric-key part as well?  In the
latter case, the "max_fragment_length" and "truncated_hmac" extensions
would also have to be used in a ciphersuite-specific way.



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