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.