[TLS] Renegotiation and TLSNotary

[Sergio Demian Lerner <[e-mail]>]

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