Subject: [TLS] TLS Hello Request for Connection Request

From: "Michael Staubermann" <[email-masked]>
Date: Wed, 29 Feb 2012 10:03:31 +0100

Our group is planning to use the TLS Hello Request Message (sent from the
server to the client) to request a new

TLS Connection establishment from the Client to the Server (where the Client
has the choice to ignore the Hello Request).

The environment/preconditions:

TLS is used over a non-IP, reliable transport layer over a shared medium
(wireless media or wired bus).

The reliable transport layer does not support session open/close (i.e.
Connect/Disconnect), the association (channel) 

between Client and server is implicit open. The underlying Reliable
Transport Layer uses an (AES-CMAC) 

authentication with a shared secret known only to one client and server
pair, and the Hello Request is 

sent over this authenticated channel from the Server to the Client.

The Hello Request Format is standard as per RFC5246:
Content-Type=Handshake(21), Message Type=Hello Request(0),
MsgLength/ContentLength=0, Major=3 and Minor=2 or 3

(TLS1.1/TLS1.2) Version 

>From RFC5246 (7.4.1.1):

HelloRequest is a simple notification that the client should begin the
negotiation process *anew*.  In response, the client should send a
ClientHello message when convenient.  This message is not intended to
establish which side is the client or server but merely to initiate a new
negotiation. 

Question: 

Is it ok to use the Hello Request Message for the above mentioned purpose
(initiate a non existing TLS Connection), 

or may it collide in the future with a use of Hello Request with slightly
other semantics? 

The word "anew" rises my attention.

Best regards,

   Michael Staubermann

---

From: Marsh Ray <[email-masked]>
Date: Wed, 29 Feb 2012 12:41:39 -0600

On 02/29/2012 03:03 AM, Michael Staubermann wrote:
> Our group is planning to use the TLS Hello Request Message (sent from
> the server to the client) to request a new
> TLS Connection establishment from the Client to the Server (where the
> Client has the choice to ignore the Hello Request).
>[...]
> Is it ok to use the Hello Request Message for the above mentioned
> purpose (initiate a non existing TLS Connection),

Not within the definition of TLS, as I read it.

TLS has only two defined ways to initiate a connection:
An SSL 3.0/TLS format ClientHello message
An SSLv2-compatible ClientHello message (deprecated)

> or may it collide in the future with a use of Hello Request with
> slightly other semantics?

It's not so much that, after all no one is likely sending or accepting 
HelloRequests that you might fail to interoperate with now.

It's that the real TLS ClientHello and ServerHello messages have fields 
necessary for version negotiation. If you go back through the archives 
of this list, there has been plenty of discussion about the exact 
details of this process. There are also protections against things like 
version downgrade attacks that you only get when using the official message.

> The word "anew" rises my attention.

It's interesting that the TLS RFCs actually say
"The HelloRequest message MAY be sent by the server at any time." But 
clearly the intent here is any time after an initial handshake. 
Implementations probably vary significantly in their handling of a 
HelloRequest message sent during an initial (or subsequent) handshake.

Note that TLS defines the "client" as "The application entity that 
initiates a TLS connection to a server." and "server" as "The server is 
the application entity that responds to requests for connections from 
clients." So the server cannot initiate the connection, by definition.

But of course, TLS only defines TLS. What you want to do at lower or 
upper protocol layers, or on the same channel before or after TLS is 
used is your own business.

My recommendation would be to define your own super-lightweight 
transport for this purpose. Since your transport seems to have its own 
particular properties, you might consider defining a way to separate the 
proper TLS records from your other messages. It could be a simple TLV 
format.

You could even pick a random GUID or something to indicate the 
HelloRequest-like semantics you need. Anything could work, but it's 
probably better if it *doesn't* look too much like an actual TLS message 
when it's not actually valid TLS.

- Marsh

P.S. I suspect you might find it useful to have a "TLS-carrying 
connection closed" message as well.