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

From: Pascal Urien <[email-masked]>
Date: Tue, 6 Jul 2010 07:49:07 +0200

Hi All

I just dowbloaded this draft dealing with tripartite diffie hellman
for tls, based on ec pairing

http://www.ietf.org/staging/draft-urien-tls-dh-tripartite-00.txt

I am ready to comment it for the next ietf meeting

Best Regards

Pascal

Abstract

   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.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 6 Jul 2010 08:17:48 -0700

At 7:49 AM +0200 7/6/10, Pascal Urien wrote:
>   could recover the protected information when needed.

Some people might want that, yes. But...

>   The proposed

Isn't that awfully heavy-weight to achieve the goal? It would be far simpler (that is, it would require zero protocol change) to simply have the client or the server or both record the master secret and give it to the TTP.

--Paul Hoffman, Director
--VPN Consortium

---

From: Pascal Urien <[email-masked]>
Date: Wed, 7 Jul 2010 09:48:30 +0200

Hi Paul,

> Isn't that awfully heavy-weight to achieve the goal? It would be far simpler (that is, it would require zero protocol change) to simply have the client or the server or both record the master secre…

 How the client and the server will agree for a particular TTP?.  A
TTP public key is needed ? DH public key in TDH
 How and how long will they store the master secret?. IN TDH no master
secret storage
 How will they send the master secret to the TTP?. No required  with TDH

Pascal

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Jul 2010 07:56:48 -0700

At 9:48 AM +0200 7/7/10, Pascal Urien wrote:
> How the client and the server will agree for a particular TTP?.

Out of band, just as in your proposal.

> A

No TTP public key is needed; either the client or the server can give the master secret to the TTP in whatever manner they want (using the same level of security as the TLS session, one hopes).

> How and how long will they store the master secret?. IN TDH no master

As I said, there is no protocol change. The client and server destroy their copy of the master key as soon as they would now. Assuming that the TTP stores the master secret in my proposal using the same level of security as the TTP protects its contribution to the TDH in yours, there is no difference.

> How will they send the master secret to the TTP?. No required  with TDH

Again: it's up to them. One obvious choice would be "over TLS that has the same strength as the tunnel they just created with each other". Or CMS, if it doesn't have to be instant.

Can you say why you would expect people to add a significant new crypto module to TLS just to get what they can do now with no changes? Is the advantage of "no passing back the master secret" really worth "changing TLS significantly for this purpose"?

--Paul Hoffman, Director
--VPN Consortium

---

From: Pascal Urien <[email-masked]>
Date: Wed, 7 Jul 2010 17:36:55 +0200

Hi Paul

 TLS until now is bipartite. DH is a bipartite shared secret.

 TLS with tripartite could be TDH.

 ECC is already supported by TLS. Why supported ECC and RSA. Probably
because ECC is the way to go...

 Paring (and TDH) works with ECC. Fast pairing looks possible. Finally
TDH is a new way to compute a premastersecret with ECC

Today TLS use g^ab, which means bipartite
 with TDH it will use e(g^a,g^b)^c, which is natively tripartite

Pascal

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Jul 2010 09:01:06 -0700

> with TDH it will use e(g^a,g^b)^c, which is natively tripartite

All true, and but not related to the questions I asked about the motivation for adding this to TLS. Just because it exists, it doesn't mean we want to add it to TLS, particularly if the motivating goal is achievable with no changes to the protocol.

--Paul Hoffman, Director
--VPN Consortium

---

From: Pascal Urien <[email-masked]>
Date: Wed, 7 Jul 2010 18:29:56 +0200

Hi Paul

1) Motivation. Third Trusted Party (TTP) is something that can be
usefull in electronic transcation based (secured) by TLS

2) TLS has been designed for bipartite (client/server exchange) .They
are resonable security asumptions about the fact that DH (or RSA) is
not breakable

3) There are reasonable security considerations about the fact that
TDH is not breakable, so a TTP scheme is built over some security
foundations

4) Is there similar security fondations/considerations  for the use of
TLS "as it is" with a TTP ?

Pascal

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Jul 2010 09:54:22 -0700

>usefull in electronic transcation based (secured) by TLS

Fully agree. That is, I don't have such a requirement, but I have heard others who do.

>are resonable security asumptions about the fact that DH (or RSA) is

True.

>TDH is not breakable, so a TTP scheme is built over some security

Probably true, but "send a key over TLS" and CMS key wrapping probably have stronger security foundations. That is, there has been less study of TDH than using TLS or CMS to transmit keys.

>TLS "as it is" with a TTP ?

Yes, definitely. Finding the key for all encryption methods commonly used in TLS is considered to be as difficult as using brute force. Finding the key for all key establishment methods commonly used in TLS is considered to be a known amount of work based on the length of the keys used in the key establishment method.

Are you proposing that if one party sends the master secret itself in an established TLS tunnel,  an attacker has to do less effort to determine the key for that tunnel?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Wed, 7 Jul 2010 12:56:13 -0400

First - no, using a two-party protocol to connect three parties is NOT a
good idea. "Just tell the key to the 3rd party" - just say no (if you want
to stay secure, that is).

I don't know how much need there is to extend key agreement to 3-party.

But if there is interest in adding multi-party (say 3-party) communications,
then 3-way DH seems to be the right way to do it.

On 7/7/10 12:01 , "Paul Hoffman" <[email-masked]> wrote:

> All true, and but not related to the questions I asked about the motivation
> for adding this to TLS. Just because it exists, it doesn't mean we want to add
> it to TLS, particularly if the motivating goal is achievable with no changes
> to the protocol.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Jul 2010 10:19:52 -0700

>to stay secure, that is).

Correct, but that's not what is being proposed here. Pascal's draft says
   The goal of this draft is to support a Trusted Third Party (TTP) that
   could recover the protected information when needed.
I assume that means *after* the TLS session, not during it. Pascal: if I'm wrong here, by all means say so.

>I don't know how much need there is to extend key agreement to 3-party.

Exactly.

>then 3-way DH seems to be the right way to do it.

Fully agree, but I don't think that is what is motivating Pascal's document.

--Paul Hoffman, Director
--VPN Consortium

---

From: Martin Rex <[email-masked]>
Date: Wed, 7 Jul 2010 19:28:24 +0200 (MEST)

>    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

---

From: Pascal Urien <[email-masked]>
Date: Wed, 7 Jul 2010 19:28:34 +0200

> I assume that means *after* the TLS session, not during it. Pascal: if I'm wrong here, by all means say so.

"when needed" menas in my mind meanwhile or after. The TTP holds the
master secret. So it can decrypt TLS packet at anytime. Maybe in an
automatic way.. it is a TTP

Pascal

---

From: Pascal Urien <[email-masked]>
Date: Wed, 7 Jul 2010 19:42:41 +0200

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

---

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 07 Jul 2010 10:53:33 -0700

> I am ready to comment it for the next ietf meeting

Please disclose IPR encumbrances.  Somehow, I doubt that "tripartite
Diffie Hellman based on EC pairing", based on research papers
published in the last 3-4 years, is free of any IPR encumbrance.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Jul 2010 10:56:57 -0700

>automatic way.. it is a TTP

If all you want to do is decrypt packets that were collected not from within the tunnel, I propose that my "don't make changes, send keys to the TTP" proposal is better, even for "meanwhile". If you want the TTP to *participate* in the tunnel itself, not just decrypt as you say above, then Uri is right and your proposal is worthwhile. However, then you need to say that in your draft.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 7 Jul 2010 14:15:31 -0400

Can you elaborate on the security considerations behind "just say no"?

S/MIME uses key transport for n-party communications - a message
encryption key distributed to 9 recipients is no more vulnerable to
attack than if it were distributed to a single recipient.  (The
assumption that 10 participants adequately protect shared keys applies
equally to key distribution and cooperative key establishment.)

Multicast protocols use key transport - a requirement for all-party
cooperative key establishment would make setup painful and late joins
practically impossible.

So what security advantages would 3-way (or n-way) DH have over multiple
2-way DH followed by key transport?

Dave

-----Original Message-----
From: Blumenthal, Uri - 0668 - MITLL

First - no, using a two-party protocol to connect three parties is NOT a
good idea. "Just tell the key to the 3rd party" - just say no (if you
want
to stay secure, that is).

But if there is interest in adding multi-party (say 3-party)
communications,
then 3-way DH seems to be the right way to do it.

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Wed, 7 Jul 2010 14:27:21 -0400

Sure. There is a difference between one party (that controls/owns the data
and the key(s) to encrypt/decrypt it) sending that data (or those keys - in
email or otherwise) to multiple destinations, and a protocol that provides
_mutual interlocking_ authentication of the participating parties to
establish a secure channel between them. (Not that TLS does it, actually -
so perhaps this conversation is moot.)

The advantage you're asking about is in the "mutual interlocked" part.

If in your scenario it's OK for one party to generate a key, and then
deliver it to whoever you say should have it - fine (the standard NSA
pattern, used since pre-NSA days and pre-WWII).

In my scenario I don't trust another party to bear the sole responsibility
for the session key I use, and want to actively contribute to its
derivation, having the other party authenticated via _interlocked_ protocol
in the process.

---

From: Martin Rex <[email-masked]>
Date: Wed, 7 Jul 2010 20:28:49 +0200 (MEST)

> mind TTP is an authorized observer

The problem in your proposal is the idea that this authorized observer
should implicitly be authorized to collect and archive the entire
communication at the transport level.

The idea of storing (collecting and archiving) is where this thing becomes
an illegal privacy violation under the data protection laws.  There is
_no_ level of trust which could fix this problem.  The data protection laws
would be pretty useless if you could subvert them so easily.

Take a look at a decision of the german constitutional court.
(URL to the english language press release)
http://www.bverfg.de/pressemitteilungen/bvg10-011en.html

There you can see that even the combined power of a european data
retention directive plus german government and parliament can fail
in creating a law for collecting an archiving _MUCH_ less data than
what your proposal is about.  They did _NOT_ ask for collecting
and archiving any _content_ of the communication, mind you!

A shotgun approach ("shoot 'em all and let god sort 'em out") is
an unconditionally bad idea and completely incompatible with the
idea behind data privacy and data protection laws.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 7 Jul 2010 14:39:12 -0400

NSA cares about mutual interlocking - the Fortezza Key Establishment
Algorithm (KEA) has properties similar to MQV, and supports both
short-term and long-term random contributions from two parties.

But does interlocking 3 or more parties provide benefits over pairwise
MQV when the end result in either case is symmetric traffic keys shared
among all parties?

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Blumenthal, Uri - 0668 - MITLL
Sent: Wednesday, July 07, 2010 2:27 PM
To: Kemp, David P.; [email-masked]
Subject: Re: [TLS] draft-urien-tls-dh-tripartite-00

Sure. There is a difference between one party (that controls/owns the
data
and the key(s) to encrypt/decrypt it) sending that data (or those keys -
in
email or otherwise) to multiple destinations, and a protocol that
provides
_mutual interlocking_ authentication of the participating parties to
establish a secure channel between them. (Not that TLS does it, actually
-
so perhaps this conversation is moot.)

In my scenario I don't trust another party to bear the sole
responsibility
for the session key I use, and want to actively contribute to its
derivation, having the other party authenticated via _interlocked_
protocol
in the process.

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Wed, 7 Jul 2010 14:54:45 -0400

In short: I think yes. Otherwise you aren't interlocking.

---

From: Marsh Ray <[email-masked]>
Date: Wed, 07 Jul 2010 18:57:19 -0500

On 07/07/2010 01:28 PM, Martin Rex wrote:
> an illegal privacy violation under the data protection laws.

Who says they're not all your computers or it's not your data in the 
first place? There's a time and place for network monitoring/decryption 
tools.

That said, I agree that there are probably simpler and less IPR-risky 
solutions. Just generate the premaster secret using a method known to 
whomever you want to know it, leak it via a secure subchannel, configure 
the client to trust your actively-intercepting CA, or whatever.

- Marsh

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 08 Jul 2010 14:55:53 +1200

"Kemp, David P." <[email-masked]> writes:

>So what security advantages would 3-way (or n-way) DH have over multiple 2-
>way DH followed by key transport?

... and cracking open a shipping container stacked full of cans of worms, why
not use one of a gazillion broadcast encryption/group key management protocols
to do this?  Why tripartite DH in particular?

Peter.

---

From: Martin Rex <[email-masked]>
Date: Thu, 8 Jul 2010 07:03:06 +0200 (MEST)

> first place? There's a time and place for network monitoring/decryption 

If you yourself are both peers _and_ the trusted third party then
the data protection laws don't have a grip, because you can not
sue yourself against illegally storing data about yourself.

But at that point the entire technology is pretty useless.

The legel trouble with collecting and archiving blindly at the
transport level begin if the collected data contains personally
identifiable information about someone else, and it quickly becomes
_unsolvable_ legal trouble if only one of the peers is you and the
other peer, the TTP or both are somebody else.

In essence, data protection law (at german version of it for several
decades) requires you to avoid collecting storing and processing data
whereever it can be avoided.  And it absolutely requires you to comply
the request for deletion of any data about an identifiable subject
that you failed to avoid collecting.

A few years ago the was a german court ruling against the largest
german ISP for not immediately deleting after use records about the
dynamic IP address assignment of a DSL flatrate customer.

(german it new site):
http://www.heise.de/newsticker/meldung/T-Online-darf-nur-fuer-Rechnung-noetige-Verbindungsdaten-speichern-168803.html

The ISP was "encouraged" to comply with deleting records of IP-Address
assignments immediately after use with a fine of 100.000 Euro for further
non-compliance or 6 month in Jail for the CIO of the company.
The ISP tried all possible means to appeal but the ruling was upheld.

> the client to trust your actively-intercepting CA, or whatever.

What I dislike so much about this approach, and similarly disliked
about the 2007 proposal, is that it is the exact opposite of avoiding
to collect and store unnecessary data.   You can not possibly make
it any worse than collecting and archiving the entire communication
at the transport layer of the communication.

This approach is a square peg for a round hole.

Use PKCS#7,CMS or XMLdsig for exactly and only that data that
describes the transaction content.  Works fine and completely
without TLS-protected communication links (i.e. even offline).

-Martin