[The following exchange on the TLS WG list <tls(_at_)ietf(_dot_)org>, 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 <ietf(_at_)ietf(_dot_)org>. 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:
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
Bodo Moeller:
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?
Ari Medvinsky:
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?
Bodo Moeller:
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
[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
<david(_dot_)nospam(_dot_)hopwood(_at_)blueyonder(_dot_)co(_dot_)uk>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf