Subject: [TLS] (no subject)

From: Nicko van Someren <[email-masked]>
Date: Wed, 13 Jul 2005 16:51:18 +0100

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

---

From: "Simon Blake-Wilson" <[email-masked]>
Date: Wed, 20 Jul 2005 16:53:49 -0400

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)
> 
> 
> > >> whether curves should be negotiable on a 
> per-cipher-suite basis. My 
> > >> intuition is that the case Ari mentions is kind of a corner

---

From: Hovav Shacham <[email-masked]>
Date: 21 Jul 2005 16:35:29 -0700

"Simon Blake-Wilson" <[email-masked]> writes:

> 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.

What ciphersuites do we expect to need this mechanism?  There's the
ECC ciphersuites, for curve negotation.  Anything else?

I'd hesitate to increase the complexity of the extensions mechanism if
it's not absolutely necessary.

Hovav.

---

From: "Simon Blake-Wilson" <[email-masked]>
Date: Fri, 22 Jul 2005 12:22:22 -0400

Hi Hovav,

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.

But I think there's been consensus so far that if we're going to go for CS
specific ECC extensions, then it should be in the context of a generic
mechanism rather than something ECC specific.

Best regards. simon

> [mailto:[email-masked]] On Behalf Of Hovav Shacham
> Sent: Thursday, July 21, 2005 7:35 PM
> To: [email-masked]
> Subject: [TLS] Re: Cipher-suite specific extensions
>
>
> > 3456-bis would be required in order to specific a framework
> for cipher
> > suite specific extensions.
>
> What ciphersuites do we expect to need this mechanism?
> There's the ECC ciphersuites, for curve negotation.  Anything else?
>
> I'd hesitate to increase the complexity of the extensions
> mechanism if it's not absolutely necessary.
>
>
> Hovav.
>

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 22 Jul 2005 22:00:41 +0200

> like RSA key sizes, especially if larger key sizes take off in conjunction

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.