Re: [TLS] Renegotiation and TLSNotary

[Mike Hamburg <[e-mail]>]

Hi Sergio,

It is worth noting that MAC functions are not generally strong enough 
here.  For one thing, the MAC is meaningless to a party who doesn't know 
the key.  But even if you reveal the key afterwards, unless you're using 
a sufficiently long HMAC mode, a party who knows the key can probably 
find a message with the same MAC value.

Cheers,
-- Mike

On 03/24/2015 08:09 PM, Sergio Demian Lerner wrote:
> 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
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls