Subject: [TLS] Renegotiation and TLSNotary

From: Sergio Demian Lerner <[email-masked]>
Date: Wed, 25 Mar 2015 00:09:58 -0300

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 Mar 2015 23:32:45 -0500

Perhaps you can do a better job of explaining precisely what
information you want to provide the auditor.  It might be that I'm
tired, but tlsnotary.org does a terrible job of actually explaining
what it is for.

On 24 March 2015 at 22:09, Sergio Demian Lerner <[email-masked]> wrote:
> Or in AEAD  terminology, every packet payload additional_data would include
> the authentication tag of the previous packet.

That would be incompatible with DTLS.

---

From: Mike Hamburg <[email-masked]>
Date: Tue, 24 Mar 2015 22:50:59 -0700

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:
> 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.
>
> 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.
>
> 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  
> 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)
>
> 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 
> 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)
>
>   additional_data = seq_num +*prev_authentication_tag +
> 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
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Watson Ladd <[email-masked]>
Date: Wed, 25 Mar 2015 07:06:20 -0700

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

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.

> 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)
>
> 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
>  additional_data = seq_num + prev_authentication_tag +
>                     TLSPlaintext.type +
>                         TLSPlaintext.version
>
>  additional_data = seq_num + prev_authentication_tag +
>                     opposite_stream_prev_authentication_tag +
>                     TLSPlaintext.type +
>                         TLSPlaintext.version
>

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

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

---

From: Sergio Demian Lerner <[email-masked]>
Date: Sun, 29 Mar 2015 08:06:48 -0300

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 <[email-masked]> wrote:

> 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
>
>
> 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,
>  additional_data = seq_num + *prev_authentication_tag +
> TLS mailing [email-masked]://www.ietf.org/mailman/listinfo/tls
>
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 29 Mar 2015 14:33:52 +0300

> combination with an emulated AEAD mode, such as AES_CBC + HMAC.

Maybe I don't quite understand what this is about, but doing certain
things with partial key disclosure requires running two MACs. Perhaps
this is one of those[1]?

The issue there is that the main MAC key must be assumed to be the same
as encryption key, so one needs a second MAC that one can disclose key
for.

[1] The first such thing I ran into was escrow decryption, where one
needs an inner MAC to prevent tampering.

-Ilari