RE: [TLS] Cipher-suite specific extensions

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

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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Simon Blake-Wilson
> Sent: Wednesday, July 20, 2005 4:54 PM
> To: [e-mail]
> 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: [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
> 

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