Ciphersuite specific extensions (Last Call comment on draft-ietf-tls-rfc3546bis)

[David Hopwood <[e-mail]>]

[The following exchange on the TLS WG list <[e-mail]>, 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 <[e-mail]>. 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 <[e-mail]>



_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf