Subject: RE: [TLS] I-D ACTION:draft-ietf-tls-ecc-10.txt

From: "Ari Medvinsky" <[email-masked]>
Date: Tue, 7 Jun 2005 13:27:37 -0700

The scenario is if you have a pluggable/extensible TLS provider where
third parties can implement and plug in their own cipher suites.  A
third party may be a hardware vendor that offers perf improvements for
the ecc cipher suites.  Using my previous example, by default the TLS
provider might support:

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA with curves: secp256r1, secp384rl,
secp384rl
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA with curves: secp256r1, secp384rl,
secp384rl

Lets say the third party plugs in:
TLS_ECDH_ECDSA_WITH_RC4_128_SHA with curves: sect163k1, sect163rl,
sect163r2

Given the way the current draft is defined, there is no way for me to
send all three cipher suites in the same message because there is no
intersection between the curves.

I would suggest to modify the draft so that the new extension specifies
each ecc cipher suite (in the hello msg) with a list of supported
curves. E.g. info contained in the modified extension:

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: secp256r1, secp384rl, secp384rl
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: secp256r1, secp384rl, secp384rl
TLS_ECDH_ECDSA_WITH_RC4_128_SHA: sect163k1, sect163rl, sect163r2 

Ari Medvinsky
Program Manager
Windows Security

-----Original Message-----
From: Bodo Moeller [mailto:[email-masked]] 
Sent: Tuesday, June 07, 2005 12:11 PM
To: Ari Medvinsky
Cc: [email-masked]; [email-masked]; [email-masked]; Joshua
Ball; Jeff Spelman; Cristian Ilac; Virginia Robbins
Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-ecc-10.txt

On Tue, Jun 07, 2005 at 11:58:30AM -0700, Ari Medvinsky wrote:

> I have a question about the elliptic curve extension.  Lets say in the

> hello msg the client sends several curves to the server (e.g., 
> secp256r1, secp384rl, secp384rl) and  specifies that it supports 
> several ECC cipher suites (e.g., TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_256_WITH_AES_256_SHA).
> 
> Does this mean that for each of the above cipher suites the client 
> MUST support every curve sent in the elliptic curve extension? 
> (secp256r1, secp384rl, secp384rl)

Yes.

> Is there a way to specify via the proposed extension mechanism that 
> for TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA the client only supports 
> secp256r1 curve and for the 
> TLS_ECDHE_RSA_WITH_AES_256_WITH_AES_256_SHA the client only supports
secp384rl and secp384rl curves ?

No.  Can you motivate a scenario where this would be needed?
I wouldn't think that such a requirement would come up frequently enough
to warrant the extra complication to the protocol for a more
fine-grained curve negotiation.

There is, of course, always a possibility to work around this problem
with some protocol overhead, namely by using multiple connection
attempts with appropriately restricted parameters.  (Also, with the
TrustedAuthority client hello extension, a client that supports only
secp256r1 for ECDSA may avoid being offered an EC server certificate
using secp384r1 if different CA names are used to issue EC
certificates.)

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

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 7 Jun 2005 16:02:27 -0600

On Tue, Jun 07, 2005 at 01:27:37PM -0700, Ari Medvinsky wrote:

> third parties can implement and plug in their own cipher suites.

I see.

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.

For example, extension type 65535 in the client hello could indicate
an extension with content

      struct {
          ExtensionRestriction restriction_list<7..2^16-1>;
      } RestrictedExtensions;

where

      struct {
          CipherSuite cipher_suites<2..2^16-1>;
          Extension extension_list<1..2^16-1>;
      } ExtensionRestriction;

This would indicate that for each ExtensionRestriction, the listed
extensions apply to the listed ciphersuites only.  (The server would
collect applicable extensions from those that appear directly in the
client_hello_extension_list field of ClientHello, and those that
appear in an ExtensionRestriction naming the respective ciphersuite.)

With pluggable ciphersuites, use of the trusted_ca_keys extension
would likely be restricted to certain ciphersuites as well (if only
one of the plug-ins can make sense of a certain trusted CA
certificate, then you wouldn't want to offer it as a trusted authority
for other ciphersuites).  And certainly the client_certificate_url
extension would be ciphersuite-specific.

What do you (and others, of course) think of this approach?

---

From: EKR <[email-masked]>
Date: Sun, 19 Jun 2005 08:42:27 -0700

> defined in the successor of RFC 3456.
[...]
> What do you (and others, of course) think of this approach?

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

-Ekr

---

From: "Simon Blake-Wilson" <[email-masked]>
Date: Mon, 20 Jun 2005 14:23:21 -0400

I'm concerned that defining cipher-suite specific extensions is headed
towards "over specification".

It seems like the examples are unusual enough that performing two
handshakes, one with the "plugged cipher suites" and a second if necessary
with the "native cipher suites" might be a reasonable solution.

Just my 2c. Of course as an author of both drafts I'm baised towards
minimal changes!

Best regards. Simon

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of EKR
> Sent: Sunday, June 19, 2005 11:42 AM
> To: Bodo Moeller
> Cc: Ari Medvinsky; Jeff Spelman; [email-masked]; Joshua Ball;
> Virginia Robbins; Cristian Ilac
> Subject: [TLS] Re: Ciphersuite specific extensions
>
>
> 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...
>
> -Ekr
>