[TLS] Renegotiation and TLSNotary

[Sergio Demian Lerner <sergio at coinspect.com>]

Hi,

This is my first post to this mailing list and I if I break some prestablished rule, I apologize in advance.

One of our clients requires the notarization of TLS sessions. One interesting application I found is the TLSNotary project, but it only partially solves this problem: is only allows auditing a single stream direction, is is not compatible with TLS 1.2 nor 1.3 and it lowers considerably the protocol security. Of course he wants transparent notarization for eavy website, not a higher-level protocol provided by a website on purpose, and this is completely logical and coherent with the attributes of a notary.  

I would be interesting if TLS 1.3 could allow optional and easy notarization of the streams. TLS 1.3 has eliminated renegotiation, which may be a bulding block for notarization, so I hope in incorporates another way of providing that functionality.
 

For example: if every MAC computed included the the MAC digest of each previous message sent in that stream, then a single signature of the last MAC would be enought to validate one of the streams. Or in AEAD  terminology, every packet payload additional_data would include the authentication tag of the previous packet. 

If key renegocitation is allowed, then a renegotiation done by a third party after a protocol interaction would be enought to notariaze all previous interactions.

To get a join notarization of both streams, TLS in notarization could add a new message GetMAC that should be responded with the message SendMAC, containing the sequence number and MAC of the the last packet decrypted in the other stream (client->server). Since the MAC on one stream would contain the previous packet MAC digest, then the MAC sent with sendMAC would provide a MAC validating both streams (client->server and servcer->client)

A full communication would be

      Client                                               Server

      ClientHello                  -------->
      (client specifies a NOTARY extension somehow)        ServerHello
      .....
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

      Now the client gives the notary the control of the streams.

      The server does a renegotiation to obtain a signature of the 

      previuously sent data.

      Notary tunneled over Client                     Server

      ClientHello                  -------->
                                                      ServerHello
      .....
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

      getMAC                       -------->

                                   <--------     sendMAC

This "notarization" can only convince the notary of the encrypted information exchange, but cannot convince a third party. Also it gives the notary some control over the streams. So better than this would be that instead of getMAC/sendMAC there can be two messages getSignature/SendSignature that send a digitally signed MAC using a server's pubkey, instead of only the MAC.

Another option is that in notarization mode, each MAC sent would include the nseq and the MAC of the last packets received/sent of both streams. Then an exact reproduction of the message interaction would be available for notarization, but the seq_num of the opposed stream would need to be transmitted in the header or encrypted in the payload (it cannot be part of the additional_data because it is not known to the client, because of the delay of the network)

In AEAD terminology the first idea would be done by modifying the additional_data:

 additional_data = seq_num + prev_authentication_tag +
                    TLSPlaintext.type +
                        TLSPlaintext.version

while the second would be:

 
 additional_data = seq_num + prev_authentication_tag +
                    opposite_stream_prev_authentication_tag +
                    TLSPlaintext.type +
                        TLSPlaintext.version

Again, this would be an optional mode, orthogonal with ciphersuite chosen, extensions, etc.

I hope you find this extension as usefull as we do.  Last, we have several use cases for key renegotiation, and it's a pity it will be excluded from TLS 1.3. I will present my arguments in another e-mail.

Best regards,

--

Sergio D. Lerner

Cryptocurrency Security Auditor

Coinspect.com