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



Martin Rex wrote:
> Marsh Ray wrote:
>>
>> 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.

Where that is an issue, the S->C signaling would only happen if the
client requests it.

Still, I do not like giving up the ability to spot a patched server
talking to an unpatched client. But it may not be practical after all.

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

No, it's not that simple in reality.

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

I am a little disappointed that we don't get more input from vendors
discussing their real-world implementations.

OpenSSL, Microsoft, Mozilla, and Opera seem to have been the best in
this regard.

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

OK, but there is a bit pattern that can be XORed or some other simple
permutation to which can encode an unambiguous signal without losing
information.

Help, is there a steganographer in the house?!

- Marsh

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