Re: [TLS] Renegotiation and TLSNotary

[Watson Ladd <[e-mail]>]

On Tue, Mar 24, 2015 at 8:09 PM, Sergio Demian Lerner
<[e-mail]> 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.

What exactly is being asked for here? A signature on encrypted data is
not the same as a signature on unencrypted data, so I don't understand
what this notarisation is providing. I also don't understand what the
requirements are: does notarization have to work without modifying the
server, or the client, or both, or we can modify anything?

>
> 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.

Same question as before.

>
> 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.

I don't understand what problem notarization is supposed to solve at
the TLS layer. If you want to make an exchange irrevocable, have both
people sign it. We also removed renegotiation because no one
understood what semantics it was supposed to have.

Sincerely,
Watson Ladd
>
> Best regards,
>
> --
> Sergio D. Lerner
> Cryptocurrency Security Auditor
> Coinspect.com
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin