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

[Pascal Urien <[e-mail]>]

Hi Martin,

  Trusted Third Party means you trust this entity.

  In bipartite exchange the client trust the server. He beleives  that
the server private key (DH or RSA) is only known by the server

  In tripartite exchange the trust is shared by three entities. In my
mind TTP is an authorized observer

Pascal

2010/7/7 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
>