RE: [TLS] Cipher-suite specific extensions

["Simon Blake-Wilson" <[e-mail]>]

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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Nicko van Someren
> Sent: Wednesday, July 13, 2005 11:51 AM
> To: [e-mail]
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tls
> 


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