Re: [TLS] draft-urien-tls-dh-tripartite-00

[Martin Rex <[e-mail]>]

Pascal Urien wrote:
> 
>    Most of privacy exchanges over the Internet rely on the TLS protocol.
>    According to this protocol two entities the client and the server
>    computes a master secret from which are deduced cryptographic keys
>    used for data privacy and security. Digital transactions may deal
>    with critical information (payments ...) that need to be recorded for
>    traceability issues or for legal requirements. However messages are
>    secured by the TLS protocol, so it is not possible for a third party
>    that logs packets to perform decryption operations upon legitimate
>    requests.
> 
>    The goal of this draft is to support a Trusted Third Party (TTP) that
>    could recover the protected information when needed. The proposed
>    protocol uses the Tripartite Diffie-Hellman (tdh) algorithm based on
>    bilinear pairings over elliptic curves.


I'm sorry, but this approach appears to be built on severely flawed
assumptions.

The data integrity protection and data encryption in TLS is based
purely on symmetric crypto using SHARED secrets.  This means that
both communication peer can not only verify all application data
received from the peer, each of them can also create perfect fakes.
And if the master secret plus the randoms from the initial handshake
are shared with a misleadingly called "Trusted Third Party" (TTP),
then also that TTP can perfectly modify a communication between two
peers.

TLS cipher suites are not built to provide anything in the direction
of non-repudiation for communication contents at the transport level.

Personally, I think that the concept of "escrowing application data
at the transport level" for any kind of evidence purposes to be an
unconditionally bad idea.

Early 2007 there was a proposal (draft-housley-evidence-extns-00)
with a similar motivation, but technically correct architecture,
posted on the TLS mailing list,  IIRC, it required the peers to apply
digital signatures to application data, so that none of the parties
involved (peer and TTP) woulde be able to perfectly modify the
application data stream that was escrowed in full at the transport
level.

If there is a need to get proof/evidence for specific application-level
information, that put exactly that data -- and nothing else -- into a
digitally signed container, e.g. PKCS7,CMS or XMLdsig and have it
signed at the application level.  In several jurisdictions, this is
anyway one of the prerequisite for visualization to end users with a means
of trusted hardware before legally binding digital signatures can
be applied to data.


Digital signatures over non-canonical application data that is
arbitrarily fragmented over several different independent communication
connections, with open/dangling external references (some of which
may be filled by caches) with arbitrary amounts of intermediate
protocol layer stuffing, codepage translations and transport encodings 
is an unconditionally bad idea.

The idea of logging (let alone archiving) a complete application level
datastream for other than very short term technical problem solving
is completely incompatible with data protection laws in Europe based
on the European data protection directive if any of the data that is
exchanged is or can be related to human beings or legal entities.


Trying to think about where this technology could be used, I can
only think of scenarios that are either technically useless or
illegal privacy violations und the data protection laws in Germany
and likely most other countries of the European Union.


-Martin