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

From: "Ari Medvinsky" <[email-masked]>
Date: Tue, 7 Jun 2005 11:58:30 -0700

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)

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 ?

Ari Medvinsky
Program Manager
Windows Security

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Tuesday, May 31, 2005 12:54 PM
To: [email-masked]
Cc: [email-masked]
Subject: [TLS] I-D ACTION:draft-ietf-tls-ecc-10.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Transport Layer Security Working Group
of the IETF.

	Title		: ECC Cipher Suites for TLS
	Author(s)	: V. Gupta, et al.
	Filename	: draft-ietf-tls-ecc-10.txt
	Pages		: 35
	Date		: 2005-5-31
	
This document describes new key exchange algorithms based on Elliptic
   Curve Cryptography (ECC) for the TLS (Transport Layer Security)
   protocol.  In particular, it specifies the use of Elliptic Curve
   Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of
   Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
   authentication mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-10.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
	"get draft-ietf-tls-ecc-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-tls-ecc-10.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 7 Jun 2005 13:11:04 -0600

> support every curve sent in the elliptic curve extension? (secp256r1,

Yes.

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