Subject: Re: [TLS] TLS Hello Request for Connection Request

From: "Michael Staubermann" <[email-masked]>
Date: Sun, 4 Mar 2012 21:14:29 +0100

Marsh,

thanks for your valuable comment. 

Do you know, if this was the reason to do the "StartTLS" with a Bit in the
EAP-TLS Negotiation?

Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marsh
Ray
Sent: Wednesday, February 29, 2012 7:42 PM
To: Michael Staubermann
Cc: [email-masked]
Subject: Re: [TLS] TLS Hello Request for Connection Request

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.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Marsh Ray <[email-masked]>
Date: Thu, 08 Mar 2012 11:36:33 -0600

> thanks for your valuable comment.

Sorry for the delayed response!

> Do you know, if this was the reason to do the "StartTLS" with a Bit in the

No, I do not know.

But clearly STARTTLS protocols do share a lot of these same considerations.

- Marsh

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 8 Mar 2012 11:06:36 -0800 (PST)

Hello,

> Do you know, if this was the reason to do the "StartTLS" with a Bit in the

  With EAP the server issues requests and the client issues responses
to those requests. It's a lock-step protocol initiated by the server.
TLS is initiated by the client. To use TLS in EAP it was necessary
to have a request from the server start the whole thing off. The semantics
are "I want to authenticate you with TLS" and then the client starts TLS.
The "StartTLS" request, as well as the final, empty EAP-TLS Response
sent by the client were added to graft TLS into EAP.

  regards,

  Dan.