TLS re-negotiation vs resumption Please explain the difference between TLS re-negotiation and resumption.

My understanding is as follows: in the context of TLS 1.2, re-negotiation and resumption look the same, but the former can be started with either a HelloRequest/ClientHello from server/client while the latter can start with just with ClientHello from the client. In both cases, a client-server dialog followed by an abbreviated handshake occurs (or not ?), security parameters do not change, and new keying materials are recalculated using an "old" pre-master secret with new random numbers. 

From the record layer point of view, all re-negotiation/resumption messages  should be processed using "current record state"-- which means they are encrypted/authenticated using "current" keys.

Re-negotiation may happen in the middle of an existing session, a "session ticket" or "session Id" are not required to find "current state parameters", just 5 tuple may be used to look for proper running session context. ( is it true ?)

Moreover, resumption may happen even after actual connection has been closed (is it true? ) and we need sessionTicket or sessionId to look for security parameters and DO decryption, BUT the ClientHello message itself is encrypted.
How is this solved for TLS1.2 ?

In the context of TLS1.3, renegotiation is done by using KeyUpdate message, and is clearly described by draft, but resumption has the same issues.
How is resumption solved for TLS1.3 ?
Re-negotiation may happen in the middle of existing session, "session
  ticked" or "session Id" are not required to find "current state
  parameters", just 5 tuple may be used to look for proper running
  session context.


Yes.


  [...]BUT ClientHello message itself is encrypted. How this is solved for
  TLS1.2 ?


The ClientHello on an abbreviated handshake is in fact not encrypted. The message flow for an abbreviated handshake goes roughly as follows: Client sends unencrypted ClientHello, Server responds with ServerHello, ChangeCipherSpec and Finished message and client answers with ChangeCipherSpec and Finished message and application data. Also see page 37 of RFC 5246.


  in both cases client-server dialog follow abbreviated Handshake


No, only for session resumption the abbreviated handshake is used, for renegotiation a full handshake is performed.


  In opposite resumption may happen even after actual connection has
  been closed


Yes.


  In context of TLS1.3 renegotiation is done now using KeyUpdate message
  and clearly described by draft, but resumption has the same issues.
  How resumption is solved for TLS1.3 ?


Section 2.2 of the TLS 1.3 draft (-23) talks about the session resumption protocol flow. Section 4.6.1 talks about how the ticket mechanism works in detail. Section 4.2.11 talks about how the tickets are used in the Hello Messages. It turns out that the client may offer the server multiple PSK identities in the (cleartext!) ClientHello of which the server selects and thus "consumes" at most one and indicates which in its ServerHello message.