Subject: RE: [TLS] Proposed TLS WG recharter

From: [email-masked]
Date: Mon, 21 Nov 2005 19:15:01 +0200

Joshua, 

I'd like to better understand what would be the benefit being 
sought here?  A TLS management interface can already allow
the administrator to e.g. choose the encryption algorithm and 
hash individually, and this is mostly a user interface issue.

The only case where this fails is when no ciphersuite number has 
been assigned for the combination the administrator wants.  But 
has this been found to be a problem in practice? 

(My guess would be no -- it it were a big problem, someone
would have taken the trouble to get the numbers. And not
all of the combinations make that much sense anyway.)

Best regards,
Pasi

> -----Original Message-----
> From: Eric Rescorla
> Sent: 17 November, 2005 23:14
> To: Joshua Ball
> Cc: [email-masked]
> Subject: Re: [TLS] Proposed TLS WG recharter
> 
> "Joshua Ball" <[email-masked]> writes:
>
> > WRT 1.2, I would also like to examine the possibility of
> > designing a new ciphersuite negotiation scheme, one that allows
> > a more flexible approach to choosing the various algorithms
> > individually, rather than on a "per ciphersuite" basis. That is
> > to say, I am not against having ciphersuites as strict
> > definitions of support. In fact, I think it is crucial that we
> > maintain this notion to keep the explosion of possibilities
> > down. But this is no reason, IMHO, to not allow each individual
> > variable (i.e.  symmetric cipher, key exchange, hashes, to be
> > negotiated within a subset of those possibilities required for
> > compliance with the standard.
> >
> > Yes, this will require considerable design and implementation
> > changes to ciphersuite negotiation, but I think going forward it
> > might very well be worth it. I think it might be too early to
> > make this a goal, but is this something that we might look into?
> 
> So, my position is that this charter doesn't exclude looking
> into this, but that it says that we would need to have a strong
> argument to actually move forward with it. Does that work for
> you?
> 
> -Ekr

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

---

From: "Salowey, Joe" <[email-masked]>
Date: Tue, 29 Nov 2005 09:37:23 -0800

There could be advantage in allowing the authenticated key exchange to
be negotiated separately from record layer protection (integrity and
encryption).   The dependencies between the two are fairly well
understood and it would allow new record layer protection schemes to be
used by different key exchange mechanisms and vice versa without having
to define new ciphersuites for every combination.  

I would rather not see more fine grained negotiation especially in the
record layer protection since the dependencies are not as well defined.
For example I think cipher and MAC algorithms are often analyzed
together and varying them independently can have unexpected results. 

Joe  

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, November 21, 2005 9:15 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [TLS] Proposed TLS WG recharter
> 
> 
> Joshua, 
> 
> The only case where this fails is when no ciphersuite number 
> has been assigned for the combination the administrator 
> wants.  But has this been found to be a problem in practice? 
> 
> would have taken the trouble to get the numbers. And not all 
> of the combinations make that much sense anyway.)
> 
> Best regards,
> Pasi
> 
> designing a 
> > > new ciphersuite negotiation scheme, one that allows a 
> more flexible 
> > > approach to choosing the various algorithms individually, rather 
> > > than on a "per ciphersuite" basis. That is to say, I am 
> not against 
> > > having ciphersuites as strict definitions of support. In fact, I 
> > > think it is crucial that we maintain this notion to keep the 
> > > explosion of possibilities down. But this is no reason, 
> IMHO, to not 
> > > allow each individual variable (i.e.  symmetric cipher, key 
> > > exchange, hashes, to be negotiated within a subset of those 
> > > possibilities required for compliance with the standard.
> > >
> > > might very well be worth it. I think it might be too 
> early to make 
> > > this a goal, but is this something that we might look into?
> > 
> > So, my position is that this charter doesn't exclude looking into 
> > this, but that it says that we would need to have a strong 
> argument to 
> > actually move forward with it. Does that work for you?
> > 
> > -Ekr
>

---

From: "Joshua Ball" <[email-masked]>
Date: Thu, 17 Nov 2005 18:23:33 -0800

Sure.

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Thursday, November 17, 2005 1:14 PM
To: Joshua Ball
Cc: [email-masked]
Subject: Re: [TLS] Proposed TLS WG recharter

"Joshua Ball" <[email-masked]> writes:
> WRT 1.2, I would also like to examine the possibility of designing a
new
> ciphersuite negotiation scheme, one that allows a more flexible
approach
> to choosing the various algorithms individually, rather than on a "per
> ciphersuite" basis. That is to say, I am not against having
ciphersuites
> as strict definitions of support. In fact, I think it is crucial that
we
> maintain this notion to keep the explosion of possibilities down. But
> this is no reason, IMHO, to not allow each individual variable (i.e.
> symmetric cipher, key exchange, hashes, to be negotiated within a
subset
> of those possibilities required for compliance with the standard. 
>
> Yes, this will require considerable design and implementation changes
to
> ciphersuite negotiation, but I think going forward it might very well
be
> worth it. I think it might be too early to make this a goal, but is
this
> something that we might look into? 

-Ekr

---

From: "Joshua Ball" <[email-masked]>
Date: Mon, 21 Nov 2005 18:04:13 -0800

Pasi,

I completely agree, this hasn't been a problem, nor do all combinations
make sense. And believe me, I am not looking to make all combinations of
ciphersuites out there part of the standard. I think that just because
we can theoretically negotiate everything, doesn't necessarily mean that
all of those combinations should be part of the standard. We could, for
example, just declare a subset of those ciphersuites be required for
compatibility, as we do now. 

I guess my thought was that we are already seeing cipher suites
negotiated outside the scope of the base protocol (i.e. ECC curves).
Additionally we now have a problem with hashes that are becoming
compromised. And who knows what the next issue might be. In particular,
if we are going to gut the current MD5 and SHA1 out of the protocol
innards, and replace it with a new hash, how do we specify this? An
extension? A new protocol version? Is that the easy way or the right
way? What happens when the new hash is broken?

My suggestion is that we have a discussion on the benefits of tweaking
the cipher suite selection protocol to include the negotiation of the
innards as well as optional parameters (like curves), making it cleaner
and open to possible problems we have in the future. If, after looking
at this it doesn't seem to solve a problem (cleaner than extension
hacks) we can drop it. 

We have extensions for a reason. And they work (wonderfully). But they
also expose deficiencies in the usability of the protocol that I think
we should at least address objectively. Now one could argue this ad
nauseam, but I think there is a reasonable distinction between, say a
server name extension and a curve or hash selection extension. The
former never being intended for the protocol, the latter arguably so.

Anyway, this is clearly not a critical issue. We have patches to make
this work without it. It is something I would like to discuss, but, my
main concern is one of aesthetics, simplicity, and future expandability.

joshua

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, November 21, 2005 9:15 AM
To: [email-masked]; Joshua Ball
Cc: [email-masked]
Subject: RE: [TLS] Proposed TLS WG recharter

Joshua, 

Best regards,
Pasi