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

From: "Ari Medvinsky" <[email-masked]>
Date: Wed, 24 Aug 2005 10:46:14 -0700

Actually it is not 1-1 it is 2-1 in favor of modifying the draft.  Nicko
from Ncipher agreed with my position. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eric Rescorla
Sent: Wednesday, August 24, 2005 10:43 AM
To: Simon Blake-Wilson
Cc: [email-masked]
Subject: Re: [TLS] Re: Cipher-suite specific extensions

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

> Hi folks,
>
> By my count the results of my informal poll on whether people support 
> adding cipher-suite specific extensions to the TLS extensions and ECC 
> in TLS docs are currently 1-1.
>
> I don't think that shows sufficient support for making the changes to 
> add cipher-suite specific support so unless more people speak up I 
> suggest we move forward with the two documents without cipher-suite 
> specific extension support.

<Speaking as chair>

This is my assessment as well. 

As I understand the situation, we're ready to forward this document to
the IESG at this point. Simon, do you have anything else to do before
you're ready for that?

Thanks,
-Ekr

_______________________________________________
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: "Ari Medvinsky" <[email-masked]>
Date: Wed, 24 Aug 2005 10:52:59 -0700

Simon,

In case you missed Nicko's email regarding ECC cipher suites I am
forwarding his email (see below).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Nicko van Someren
Sent: Wednesday, July 13, 2005 8: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.