Re: [TLS] Renegotiation and TLSNotary

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

Yes, you're right that the MAC construction in GCM allows the key owner to
find colissions. I was thinking that the auditing mode would be used in
combination with an emulated AEAD mode, such as AES_CBC + HMAC.

Best regards,
 Sergio.

On Wed, Mar 25, 2015 at 2:50 AM, Mike Hamburg <[e-mail]> wrote:

>  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 [e-mail]://www.ietf.org/mailman/listinfo/tls
>
>
>


-- 
Sergio D. Lerner
Cryptocurrency Security Auditor
Coinspect.com