Subject: RE: Ciphersuite specific extensions (was: Re: [TLS] I-D ACTION:draft-ietf-tls-ecc-10.txt)

From: "Ari Medvinsky" <[email-masked]>
Date: Wed, 8 Jun 2005 09:40:54 -0700

I like this idea, I think it covers well the ecc cipher suite/curve
mapping problem.  Are you proposing then to modify the ecc draft to take
a dependency on the next rev of rfc3546?  

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

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

> The scenario is if you have a pluggable/extensible TLS provider where 
> 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?

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

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 8 Jun 2005 11:48:42 -0600

> a dependency on the next rev of rfc3546?  

Yes.  I hope that it is agreed to change the TLS Extensions
specification like this or similar.  The TLS-ECC specification should
cite the successor of RFC 3546, thus resolving the issue.

(Actually, the TLS-ECC specification already *has* to cite the
successor of RFC 3546 because TLS-ECC, if published as an
Informational RFC, couldn't define it's own TLS extensions
according to RFC 3546.  draft-ietf-tls-rfc3546bis-##.txt
has weaker requirements so that an Informational RFC can
define new extensions.)

Bodo

[I have copied this message to the other authors of
draft-ietf-tls-rfc3546bis-01.txt as well (this is a separate mailing to
[email-masked] which otherwise complains about "too many recipients").
I'd really like to hear more opinions!]

> ACTION:draft-ietf-tls-ecc-10.txt)
[...]

---

From: David Hopwood <[email-masked]>
Date: Wed, 08 Jun 2005 23:23:32 +0100

[The following exchange on the TLS WG list <[email-masked]>, comments on
<http://www.rfc-editor.org/internet-drafts/draft-ietf-tls-ecc-10.txt> and
<http://www.rfc-editor.org/internet-drafts/draft-ietf-tls-rfc3546bis-01.txt>.

Since the latter is in IETF-wide Last Call, it should have been
cc:d to <[email-masked]>. As one of the authors of RFC3546bis, I'm
correcting that oversight now. I'll make my own comments separately.

Technically, the deadline for comments on RFC3546bis was 2005-06-02.
However, note that the only motivation for RFC3546bis is to make a
change needed to support draft-ietf-tls-ecc (allowing extensions to be
defined by Informational RFCs). It was arguably an oversight to put
RFC3546bis into Last Call before draft-ietf-tls-ecc.]

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)

[The answer is 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?

Bodo Moeller replied:
> 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.)

Ari Medvinsky:
> 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 

Bodo Moeller:
> [This time I am copying to the other authors of
> draft-ietf-tls-rfc3546bis-01.txt as well, I'd really like to hear more
> opinions!]

-- 
David Hopwood <[email-masked]>