Re: [TLS] Proposal for hybrid solution using most of the ideas
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TLS] Proposal for hybrid solution using most of the ideas



Marsh Ray wrote:
> 
> So using extensions (even when both ends support TLS 1.1) would
> significantly change the client hello for many current clients? Yngve of
> Opera and Nelson of Mozilla had posted some connection logic that didn't
> work quite like that. But now that you mention it that is what I see
> from typical non-browser clients.
> 
> Back to unified SSL/TLS solutions then.
> 
> Looks like C->S signaling could be achieved back to SSLv2 with the magic
> cipher suite technique.
> 
> For S->C, setting that high bit in the version field is looking not so
> bad now.
> 
> RFC 4346:
> > server_version
> >       This field will contain the lower of that suggested by the client
> >       in the client hello and the highest supported by the server.
> 
> What worries me is that a great many inspecting firewalls are going to
> see that and freak out because the server is replying with a version
> higher than the client.

I'm somewhat more worried about breaking interop with SSL and TLS peers
than confusing inspecting firewalls.

It is the IETF that defines how TLS clients and TLS servers can negotiate
a change in protocol and consensually communicate with modified
semantics.  If they want to filter on "signatures" of known attacks,
fine, but they must not make flawed assumptions about evolvement
of network or transport-level protocols.

> 
> Perhaps those nice, friendly, and helpful networking hardware and
> software vendors on this list will offer some lab time to check this out?

Of course, if vendors/suppliers are listening in to this discussion,
it would be interesting to hear their opinion on what kind of changes
might upset their equiment!


> 
> Another possibility is bit 15 of cipher_suite, assuming there will not
> be a need for 32769 different cipher suites before extensions become usable.

The ciphersuite number space is dived into three ranges:

http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-3

So you can not just shave off one bit at one end.

Same for compression identifiers (3 ranges):

http://www.iana.org/assignments/comp-meth-ids/comp-meth-ids.xhtml


-Martin


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.