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

On Wed, Jun 08, 2005 at 09:40:54AM -0700, Ari Medvinsky wrote:

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

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
tls@ietf.org which otherwise complains about "too many recipients").
I'd really like to hear more opinions!]

> From: Bodo Moeller [mailto:bmoeller@acm.org] 
> Sent: Tuesday, June 07, 2005 3:02 PM
> To: Ari Medvinsky
> Cc: tls@ietf.org; vipul.gupta@sun.com; sblakewilson@bcisse.com; Joshua
> Ball; Jeff Spelman; Cristian Ilac; Virginia Robbins
> Subject: Ciphersuite specific extensions (was: Re: [TLS] I-D
> ACTION:draft-ietf-tls-ecc-10.txt)
[...]
> 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
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls