Subject: RE: [TLS] Re: Ciphersuite specific extensions

From: "Ari Medvinsky" <[email-masked]>
Date: Mon, 20 Jun 2005 11:59:44 -0700

Simon Blake-Wilson <[email-masked]> writes:

>>>> I'm concerned that defining cipher-suite specific extensions is
headed >>>> towards "over specification".

Hmmm ... The ECC draft as it stands, already introduces a new ECC
specific extension message, so according to the above view it is already
"over specified".  
I am advocating that since the draft already defines a new curve
extension msg, lets make this message explicit enough to identify which
curve pertains to which ECC cipher suite.

Ari Medvinsky
Program Manager
Windows Security

-----Original Message-----
From: Simon Blake-Wilson [mailto:[email-masked]] 
Sent: Monday, June 20, 2005 11:23 AM
To: 'EKR'; 'Bodo Moeller'
Cc: Ari Medvinsky; Jeff Spelman; [email-masked]; Joshua Ball; Virginia
Robbins; Cristian Ilac
Subject: RE: [TLS] Re: Ciphersuite specific extensions

I'm concerned that defining cipher-suite specific extensions is headed
towards "over specification".

It seems like the examples are unusual enough that performing two
handshakes, one with the "plugged cipher suites" and a second if
necessary with the "native cipher suites" might be a reasonable
solution.

Just my 2c. Of course as an author of both drafts I'm baised towards
minimal changes!

Best regards. Simon

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of EKR
> Sent: Sunday, June 19, 2005 11:42 AM
> To: Bodo Moeller
> Cc: Ari Medvinsky; Jeff Spelman; [email-masked]; Joshua Ball; Virginia 
> Robbins; Cristian Ilac
> Subject: [TLS] Re: Ciphersuite specific extensions
>
>
> Bodo Moeller <[email-masked]> writes:
>
> > 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.
> [...]
> > What do you (and others, of course) think of this approach?
>
> This is a big change and I don't want to make this a gating factor for

> advancing the ECC draft.
>
> WG members: I'd like to come to some resolution on the basic issue of 
> whether curves should be negotiable on a per-cipher-suite basis. My 
> intuition is that the case Ari mentions is kind of a corner case--most

> SSL/TLS implementations aren't assembled pluggably like this. But, I'm

> happy to listen to arguments that I'm wrong here...
>
> -Ekr
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tls
>

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