Subject: RE: [TLS] Cipher-suite specific extensions

From: "Ari Medvinsky" <[email-masked]>
Date: Tue, 16 Aug 2005 09:02:38 -0700

Simon,

I like your proposal, I think it makes sense. Are you planning to add
text to the ECC draft to state that the new ECC specific extension can
be sent across using the mech. below?
Thanks,

Ari Medvinsky
Program Manager 
Windows Security

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Simon Blake-Wilson
Sent: Tuesday, August 16, 2005 6:30 AM
To: [email-masked]
Subject: RE: [TLS] Cipher-suite specific extensions

Hi folks,

There's been very little feedback on the proposal I sent out suggesting
syntax for cipher suite specific extensions. Can I take this as meaning
that not many people care and we can move forward with the TLS
extensions and ECC documents as they are, deferring this issue to future
I-Ds? If not, please respond stating that you like my proposal, or
providing specific text for a counter proposal.

Best regards. simon

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Simon Blake-Wilson
> Sent: Wednesday, July 20, 2005 4:54 PM
> To: [email-masked]
> Subject: RE: [TLS] Cipher-suite specific extensions
> 
> 
> 
> Hi folks,
> 
> I thought it might be worth considering how much of a change to RFC 
> 3456-bis would be required in order to specific a framework for cipher

> suite specific extensions. The text below is an off-the-top-of-my-head

> attempt at some text aiming to introduce support with minimal changes.
> 
> Any thoughts on whether the text below would be sufficient (or whether

> I'm totally missing the point) would be much appreciated. It seems to 
> me that if the approach is sufficient then it could be added quickly 
> to RFC 3456-bis.
> (And if this is all that has to be done to 3456-bis to close this 
> discussion and move forward then I can live with it!)
> 
> Best regards. Simon
> 
> Insert into 3456-bis in Section 2.3 below the definition of
> "Extension":
> 
> ""extension_data" may contain any information pertinent to the 
> extension using any syntax. All the extensions defined in this 
> document apply generically to all cipher suites, but future extensions

> may be "cipher suite dependent" - i.e. the options negotiated may 
> differ depending on the selected cipher suite. For such cipher suite 
> specific extensions, "extension_data" SHOULD contain 
> "CSSpecificExtension" defined as follows:
> 
> struct {
>    CipherSuite   cipher_suites<2...2^16-1>;
>    opaque        cs_specific_extension_data<0...2^16-1>
> } CSSpecificExtensionInfo ;
> 
> struct {
>    CSSpecificExtensionInfo cs_specific_extension_info_list<1...2^16-1>
> } CSSpecificExtension ;
> 
> Where:
> 
> - "cipher_suites" identifies a list of cipher suites.
> 
> - "cs_specific_extension_data" contains extension specific information

> pertinent to the preceding list of cipher suites.
> 
> Note that the set of cipher suites in any cipher suite specific 
> extension may be different from the list of cipher suites in the 
> client hello. This allows, for example, the extension to take a fixed 
> value regardless of which cipher suites are being requested by the 
> client."
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Nicko van Someren
> > Sent: Wednesday, July 13, 2005 11:51 AM
> > To: [email-masked]
> > Subject: [TLS] (no subject)
> > 
> > 
> > On Mon, 20 Jun 2005 at 11:59:16 -0600, Bodo Moeller wrote:
> > 
> > > On Mon, Jun 20, 2005 at 10:33:51AM -0700, Ari Medvinsky wrote:
> > >
> > > >>> 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.
> > >
> > > >> 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...
> > >
> > > > 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.
> > >
> > > 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.
> > 
> > Sorry arrive late on this one but I've been having ongoing trouble 
> > getting messages through to this list.  Hopefully this
> message will
> > make it.  Here's a repeat of what I tried to send before:
> > 
> > As a vendor of widely used hardware for handling the crypto in TLS 
> > session negotiations I would like to lend my support for
> Ari's model
> > of being able to specify specific extensions on specific cipher 
> > suits, and in particular specifying different ECC curves on 
> > different suits.  While this seems like unnecessary complication it 
> > actually saves implementers from much worse complication if you do 
> > it the other way.  Here's why:
> > 
> > When implementing crypto in hardware, and in particular when 
> > implementing ECC, it is common for various types of
> hardware to have
> > quite rigid limitations regarding the curve parameters.  It
> is also
> > the case that software implementations of ECC often have
> limitations
> > due to the patent minefield in this space.  This will be worst on 
> > hardware like ECC smartcards being used for client authentication 
> > but is also the case even on big, fast ECC chips from Motorola or 
> > software libraries which have been carefully constructed to skirt 
> > around IP issues.  Due to the fragmented nature of the ECC market 
> > different types of hardware and software will have different 
> > limitations; some hardware might support MQV because it has a 
> > Certicom patent license but only work on binary curves
> (because they
> > are easy in hardware) while the software "fall-back" for prime 
> > curves might not support MQV at all because it lacks a license.
> So we are
> > in a situation where the intersection of supported
> parameters across
> > the whole set of cipher suites ends up being the empty set and we 
> > are stuck.
> > 
> > Eric said "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...".  My feeling, from dealing with a great many SSL 
> > implementations, is that they very much are modular in
> nature, or at
> > least their owners would like them to be :-) and that pluggable 
> > crypto is very important.  Certainly the vast majority of
> SSL stacks
> > that support hardware support it through some plug-in
> mechanism and
> > while I expect it is rare for any individual system to have more 
> > than one type of hardware plugged in at a time it is quite
> frequently the
> > case that there will be a hardware implementation and a software 
> > implementation operating side by side and, for the reasons
> outlined
> > above, this will potentially be an issue.
> > 
> > Anyway, that's my 2p (or 3.53 cents :-) worth!
> > 
> >      Cheers,
> >          Nicko van Someren
> >          CTO, nCipher Plc.
> > 
> > 
> > _______________________________________________
> > TLS mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/tls
> > 
> 
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tls
> 

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

---

From: "Simon Blake-Wilson" <[email-masked]>
Date: Tue, 16 Aug 2005 14:11:37 -0400

Hi Ari,

Yes, if the text is accepted, I would propose to rework the relevant ECC
extensions to use the CS-specific extension format.

Best regards. Simon

> From: Ari Medvinsky [mailto:[email-masked]] 
> Sent: Tuesday, August 16, 2005 12:03 PM
> To: Simon Blake-Wilson; [email-masked]
> I like your proposal, I think it makes sense. Are you 
> planning to add text to the ECC draft to state that the new 
> ECC specific extension can be sent across using the mech. 
> below? Thanks,
> 
> Ari Medvinsky
> Program Manager 
> Windows Security
> 
> There's been very little feedback on the proposal I sent out 
> suggesting syntax for cipher suite specific extensions. Can I 
> take this as meaning that not many people care and we can 
> move forward with the TLS extensions and ECC documents as 
> they are, deferring this issue to future I-Ds? If not, please 
> respond stating that you like my proposal, or providing 
> specific text for a counter proposal.
> 
> Best regards. simon
> 
> >    CSSpecificExtensionInfo 
> cs_specific_extension_info_list<1...2^16-1>
> > } CSSpecificExtension ;
> > 
> > Where:
> > 
> > > [email-masked] https://www1.ietf.org/mailman/listinfo/tls
> > > 
> > 
> >