Subject: [TLS] RE: Ciphersuite specific extensions

From: "Ari Medvinsky" <[email-masked]>
Date: Mon, 20 Jun 2005 10:33:51 -0700

I agree that relying on a general purpose mech. to be defined in the
successor of RFC 3456 may introduce a long delay before the ECC draft is
finalized into an RFC.  However, allowing third parties to plug in their
cipher suites is an  important scenario as it facilitates security
vendors to provide a significant value add (in terms of perf. + cipher
suites that adhere to local crypto standards).  

It is possible to address the cipher suite/curve mapping directly in the
ECC draft (without dependencies on a general purpose mech) as I
suggested in the earlier msg.

Thanks,

Ari Medvinsky
Program Manager
Windows Security

-----Original Message-----
From: EKR [mailto:[email-masked]] 
Sent: Sunday, June 19, 2005 8:42 AM
To: Bodo Moeller
Cc: Ari Medvinsky; Jeff Spelman; [email-masked]; Joshua Ball; Virginia
Robbins; Cristian Ilac
Subject: Re: Ciphersuite specific extensions

Bodo Moeller <[email-masked]> writes:

> On Tue, Jun 07, 2005 at 01:27:37PM -0700, Ari Medvinsky wrote:
>
>> The scenario is if you have a pluggable/extensible TLS provider where

>> third parties can implement and plug in their own cipher suites.
>
> I see.
>
> I have argued for a general mechanism for ciphersuite-dependent TLS 
> extensions in the past.  That is, instead of having individual 
> specifications defining TLS extensions provide means of restricting 
> certain extensions to certain ciphersuites, it would make sense to 
> have a mechanism that can be applied to all extensions, preferably 
> defined in the successor of RFC 3456.
[...]
> What do you (and others, of course) think of this approach?

This is a big change and I don't want to make this a gating factor for
advancing the ECC draft. 

WG members: I'd like to come to some resolution on the basic issue of
whether curves should be negotiable on a per-cipher-suite basis.
My intuition is that the case Ari mentions is kind of a corner
case--most SSL/TLS implementations aren't assembled pluggably like this.
But, I'm happy to listen to arguments that I'm wrong here...

-Ekr

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

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 20 Jun 2005 11:59:16 -0600

> suggested in the earlier msg.

I think doing this directly in the TLS-ECC specification is not the
best option because

- this would mean reinventing the wheel when other ciphersuites need
  similar mechanisms, adding some complexity to each of the affected
  specifications individually; and

- it already fails to take into account trusted_ca_keys (an extension
  defined in RFC 3456, which appears destined for ciphersuite-dependent
  use in the context of plug-ins).

Let me point out that one alternative for how to proceed is to pass
the TLS Extensions and TLS-ECC specifications without provisions for
ciphersuite-dependent negotiation, but standardize a TLS extension for
ciphersuite-dependent TLS extensions later in a separate document
("TLS-CD-Ext").  Obviously TLS-CD-Ext support couldn't be made a
"MUST" then, so for best interoperability ciphersuite-dependent TLS
extensions could be defined so as to allow them to extend the list of
ciphersuites given in the "cipher_suites filed" of the Client Hello
message -- i.e., clients can make ciphersuites invisible from servers
that do not support TLS-CD-Ext.

This will keep the basic protocols simple, but optionally provide the
desired flexibility.  At first, while TLS-CD-Ext is used only in the
context of TLS-ECC, the implementation overhead might be slightly
higher for putting this directly into the TLS-ECC specification (which
would, however, omit ciphersuite-dependent use of the trusted_ca_keys
extension); but as soon as some other set of ciphersuites has use for
TLS-CD-Ext, this more general approach should become easier to handle.

Bodo