Re: A proposal for secure videoconferencing and video messaging over the Internet

[Lynn . Wheeler]

we've had some of this discussion related to X9.59, namely that SSL verifies
that the URL used and the certificate DNS info somewhat correspond. one problem
is that many people don't necessarily arrive at a web site by actually typing
the URL ... so provided URLs are one method of attack. The other is that
certificate DNS information is typically verified by the certification authority
contacting the DNS authority. Issues with DNS hijacking (i do dns hijack of
xyz.com and then apply for certificate for xyz.com) and other exploits can be
addressed with DNS public-key (aka reliable DNS infrastructure) which could make
SSL certificates superfulous and redundant (i.e. one explaination is that SSL
certificates exist because DNS is unreliable ... but since the certification is
dependent on reliable DNS ... and a reliable DNS can be achieved with addition
of public keys to the DNS information ... then it becames possible ot obtain
public keys directly from the reliable DNS authority at the same time the other
DNS information is obtained).

the other part, is X9.59 requires that electronic payments transactions are
electronically signed  so only a specific payment might be subverted
(supplying the wrong "pay-to" value) ... but additional payments could not be
done with the information.  Note however, the wrong "pay-to" value still needs
to be a valid merchant identifiier in the payment infrastructure.

The issue then becomes that the URL was supplied to the browser by a trusted
method & a reliable DNS is available with some sort of public key authentication
(whether with public key directly from reliable DNS  or circuitous route via
a certificate which came from a certification authority which verified with a
reliable DNS).


misc. URLs:

http://www.garlic.com/~lynn/aepay4.htm
http://www.garlic.com/~lynn/

there are still some misc.; issues where the wrong "pay-to" field is supplied
for a signed payment transaction (say a hacked web site).

pieces for this opportunity include are at the international/iso level for a
global merchant identifier (effectively a "pay-to" value). A trade-group could
be setup that provided a merchant-id/publickey binding.

Even simpler yet, since a reliable DNS is already a requirement, it would be
possible to register both a public key (to address issues like DNS hijacking)
and a merchant-id. The DNS information, merchant public key, and optional
merchant-id (i.e. "pay-to" in a payment transaction) could then be provided as
part of a standard DNS operation (further illustrating certificates as being
superfulous and redundant in AADS-like public key environments).

There are still some open issues regarding trusted path for supplying URL
information and trusted browsers. Obviously trusted browswer can include things
like does the transaction the user "sees" being the same as the transaction the
user authorizes/signs  but then even simple aspects of existing SSL are also
dependent on trusted browser (i.e. the browser actually checks for valid
binding, sets up a private SSL session, etc).





To be fair, the sort of attack I described could work against SSL too.
Certificates can confirm that www.example.com is who you are
contacting, but certificates can't stop them from making their web site
look just like www.example.net's and duping people into giving payment
information to the wrong people. I think it would work especially well
against a videoconferencing system though, because there is a certain
trust inherent in face-to-face communications.

Re: A proposal for secure videoconferencing and video messaging over the Internet

[Steve Reid]

On Thu, Jul 27, 2000 at 10:18:02PM -0700, James A. Donald wrote:
> At 05:02 PM 7/27/2000 -0700, Steve Reid wrote:
>  >  Mallory sends The Real Alice an email claiming to be from The
>  > Real Bob (this can be done with the usual spoofing) , telling Alice
>  > that she can contact "him" as "Bob'"
> 
> Mallory can do this, but he cannot do it safely.  The likelihood of 
> exposure is very high, and the longer the deception continues, the greater 
> the prospect it will be exposed.

I don't believe it's more "unsafe" than any MITM attack. It's not as if
Mallory is a trusted server with a reputation to protect. Mallory could
be off somewhere in a country with no extradition treaty, receiving
anonymous payments from an interested party.

To be fair, the sort of attack I described could work against SSL too.
Certificates can confirm that www.example.com is who you are
contacting, but certificates can't stop them from making their web site
look just like www.example.net's and duping people into giving payment
information to the wrong people. I think it would work especially well
against a videoconferencing system though, because there is a certain
trust inherent in face-to-face communications.

> If this is Alice's first contact with Bob through the secure protocol, she 
> will surely mention how she obtained his address, exposing Mallory.

If Alice's first contact with Bob is something like, "Hi Bob, Carol
sent me your address...", what are the odds that either Alice or Bob
will confirm with Carol that she was the one who sent the information?

I don't think we can depend on ad-hoc social protocols to pick up the
slack where carefully designed cryptographic protocols have failed.

> Suppose Mallory gets away with it once.  He cannot go on getting away with 
> it indefinitely.

He doesn't have to get away with it indefinately, just long enough for
it to be worthwhile.

Re: A proposal for secure videoconferencing and video messaging over the Internet

[amanda]

Perhaps you wouldn't trust your WOT with you life, but at least you know
that there is some accountability in the signature chain. If you find that 
 
Mallory has a key that says "Bob'" then you can follow the
signatures. When you find the person who admits that he signed a key that
he didn't verify then you can kick his sorry ass.

The trust metric doesn't have to be boolean. Look at Verisign's WOT, where
everybody have a number of points. Bank Managers start with 100 points and 

you and me start with 0 points. Your number of points increase whenever a
high-pointer signs your key. People younger than 21 gets fewer points etc.

http://www.thawte.com/certs/personal/wot/

Amanda.



On Thu, 27 Jul 2000, Eugene Leitl wrote:
> amanda writes:
>  > You are not supposed to trust key servers. It is the keys that you trust,
>  > because they are signed by someone you trust (the CA or your WOT).
>  
> I'm a bit hazy on this web of trust thing. I can trust my close
> friends (I think). I would sign their keys. They would sign mine. So
> far ok. But I'm not sure the chain letter would still work, if
> propagated long enough. The trust metric is boolean, and it does not
> use consensus, right?

Re: A proposal for secure videoconferencing and video messaging over the Internet

[James A. Donald]

 --
At 05:02 PM 7/27/2000 -0700, Steve Reid wrote:
 > Someone can pull off a man-in-the-middle attack without having to
 > "put on make up, [and] declare himself to be the other person". I
 > think MITM could be done effectively against your protocol without
 > requiring special help from the server.  Some trivial misdirection
 > is all that is required...
 >
 > [...]
 >
 >  Mallory sends The Real Alice an email claiming to be from The
 > Real Bob (this can be done with the usual spoofing) , telling Alice
 > that she can contact "him" as "Bob'"

Mallory can do this, but he cannot do it safely.  The likelihood of 
exposure is very high, and the longer the deception continues, the greater 
the prospect it will be exposed.

With email, one needs multiple addresses.  With a presence protocol, one 
does not.   One's presence connection follows one around, wherever one may 
be. hence "contact me as @" messages are unusual and worthy of 
mention.

If this is Alice's first contact with Bob through the secure protocol, she 
will surely mention how she obtained his address, exposing Mallory.

If this is one of many contacts, the fact that Bob is allegedly changing 
his address will be unusual, and worthy of comment, resulting in a 
substantial risk of exposure to Mallory.

Alice may well be already on Bob's buddy list by her true account name.  If 
this is the case, the fact that the person contacting him is not on his 
buddy list will draw Bob's attention to the fact that her account name has 
mysteriously changed, which he is likely to mention, exposing Mallory.

Suppose Mallory gets away with it once.  He cannot go on getting away with 
it indefinitely.

Things will get especially difficult for Mallory if Bob and Alice check 
into a conference call, into a chat room.

Suppose Bob and Alice want to bring Carol into their discussions.  Now 
Mallory needs to have anticipated this, and fed both Bob and Alice with a 
false address for Carol.

 --digsig
  James A. Donald
  6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
  77nP+A+D30tBirybWdit4bMREKlemeSbbsWOTeFa
  4bgXGklB9iCdvrOOFS1Iw/2BB10sCfwZREolawi4V

Re: A proposal for secure videoconferencing and video messaging over the Internet

[James A. Donald]

 --
t 01:41 PM 7/27/2000 -0400, William Allen Simpson wrote:
 > I'll also note that provably secure multicast is an ongoing project
 > over at Honeyman's CITI.

I do not understand what is meant by "provably secure".  One can only prove 
security against a particular threat.  There will always be yet another 
attack.  Few things are secure against rubber hoses and hot pincers, or 
against foolishness and carelessness, which tends to be even more common 
than rubber hoses.

 --digsig
  James A. Donald
  6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
  hgnaRqit9agzllSnw2X9yTc3Mv4mTDsHIYCVcnHj
  4Wzk/YmMsX8xsDK6uqPjsGnGsXCOQbZgT9lVrh1Th

Re: A proposal for secure videoconferencing and video messaging over the Internet

[Steve Reid]

On Wed, Jul 26, 2000 at 11:53:07PM -0700, James A. Donald wrote:
> Looking at someone's face, and hearing his voice, is good enough in
> all common circumstances, and common circumstances means "where the
> customers are".

Someone can pull off a man-in-the-middle attack without having to "put
on make up, [and] declare himself to be the other person". I think MITM
could be done effectively against your protocol without requiring
special help from the server. Some trivial misdirection is all that is
required...

Suppose you have a server with a user list like this:

ID  Owner
--
Alice   The Real Alice
Bob The Real Bob
Alice'  Mallory
Bob'Mallory

Mallory sends The Real Alice an email claiming to be from The Real Bob
(this can be done with the usual spoofing), telling Alice that she can
contact "him" as "Bob'". Later, Alice has something important to
discuss with Bob, so she asks the server for credentials for "Bob'".
You can probably guess the rest, but here it is anyway:

   (Honest Server)
  / |
 /  |
/ (Mallory)
Alice <--> Bob'

Now Mallory as Alice' establishes a connection to Bob:

   (Honest Server)
  | \
  |  \
  (---Mallory---) \
Alice <--> Bob' / Alice' <--> Bob

Mallory silently forwards between Bob' and Alice'. The end result is
that The Real Alice is talking to The Real Bob and vice versa.
Meanwhile, Mallory calls up Eve: "Bring popcorn."


This might be classified as a user interface problem. But as you said,
"Looking at someone's face, and hearing his voice, is good enough in
all common circumstances". That's why this attack will work. When Alice
sees Bob's face and hears his voice, any questions she had about that
little apostrophe at the end of his user ID will disappear. When you
call someone on the phone, and get the right person, you stop wondering
if you dialed the wrong number.

Re: A proposal for secure videoconferencing and video messaging over the Internet

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

amanda wrote:
> 
> On Wed, 26 Jul 2000, Eugene Leitl wrote:
> > Clearly, you can maintain a secure connection to an anonymous party.
> 
> No you cannot. If Bob is anonymous then it is impossible for Alice to
> know if her secure connection goes to Bob or Mitch. In the classic
> man-in-the-middle attack Mitch impersonates Bob when talking to Alice and
> he impersonates Alice when talking to Bob.
> 
> [Depends on what you mean by "anonymous". If the anonymous party has a
> key he uses (i.e. the equivalent of a "nym") there is no problem at
> all and no need for a CA either... --Perry]
> 
Amanda is correct on technical points, Perry on social points.

Secure key establishment requires an exchange of identification, and 
vise versa.  That's well established in the liturature.

When you have identification, it is not anoNYMous.

Never-the-less, the identification that is exchanged may be a 
pseudo-NYM, and difficult to attach to meat space.  That may very 
well be enough for the application at hand.


> > Authentication and security only touch shoulders when you're
> > trusting the public key server
> 
> You are not supposed to trust key servers. It is the keys that you trust,
> because they are signed by someone you trust (the CA or your WOT).
> 
And I was in a hallway conversation with Honeyman yesterday, where he 
was proposing taking a randomly generated temporary public-key (he 
calls a junk key), establishing it between parties using Kerberos, 
using it to sign a document, and signing the signature via a PKIX 
timestamp.  Throw away the junk key, and you have a time verified 
signature verifiable in the future by a CA, but a completely 
anonymous signer. 

I'll also note that provably secure multicast is an ongoing project 
over at Honeyman's CITI.

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOYBz/Nm/qMj6R+sxAQEOOQP/Y8HVpOJ9QOcFUNr+/XcdKjSEipSWpHbA
ivZv/IUgLU0RG/JM/+8x0Bv8NBtglNF4x8qEzR2YK92LKCOESGNhQPSzvnarsdyP
s42X0SFUewV3uXw3Ynn2N703UgnIrbCyZxXGLsvIjLOq3Xn1j9U3Gk/3M7rLsgHw
FhQdqLzdTHY=
=v/1I
-END PGP SIGNATURE-

Re: A proposal for secure videoconferencing and video messaging over the Internet

[James A. Donald]

 --
On Wed, 26 Jul 2000, Eugene Leitl wrote:
 > > Clearly, you can maintain a secure connection to an anonymous
 > > party.

At 08:08 AM 7/27/2000 +, amanda wrote:
 > No you cannot. If Bob is anonymous then it is impossible for Alice
 > to know if her secure connection goes to Bob or Mitch.

Probably what Eugene means is that one can maintain a secure connection to 
a nymous party.

IMPP server ids normally look like email ids.

Though one might not know that [EMAIL PROTECTED] was the really an aide 
to president clinton, one could use cryptographic means to ensure that it 
was the same deep throat as gave you the good information last time, and 
not a Clinton plumber checking for leaks.

Crypto Kong  is an example of a purely nymous 
protocol.

The proposed IMPP security protocol 
 is not purely nymous, 
since one could look at Deepthroat's face and possibly recognize him, but 
it is not a true name protocol, since anyone could create an account called 
[EMAIL PROTECTED], if no other BillGates got there first.

Verisign is an example of a true name protocol.

All three protocols use public keys, but they use them to prove different 
things about the identity of the person one is talking to.

We have an accepted terminology for protocols like that of Crypto Kong -- 
nym based.

We have an accepted terminology for protocols like that of Verisign "true 
names", (an unenthusiastic minority prefer the terminology "Mark of the 
beast".)

We will need a new terminology for the protocol I have proposed.  I propose 
to call it "face based".

 --digsig
  James A. Donald
  6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
  EebeJcUrCnomop+HVlb67oO16fgvJ2Ncu1EgdT2I
  4WvqXU6X/MzeDKbKw7nWWoDSLWxj5oy30+ptrZx+P

Re: A proposal for secure videoconferencing and video messaging over the Internet

[James A. Donald]

 --
James A. Donald writes:
 >  > In real life situations where one wishes a conversation to be
 >  > secure, people are most commonly authenticated by not by true
 >  > name, but  by face.

At 02:49 PM 7/26/2000 -0700, Eugene Leitl wrote:
 > We're mixing several unrelated items in one pot here. One thing is
 > authentication, the other is securety. Authentication is when Alice
 > can prove with a very high probability that the current transaction
 > is being conducted with Bob, while in the past Alice or a party
 > Alice trusts has already had dealings with Bob. This creates a
 > machinery for maintaining a private (but publicable) list of
 > identities which can build trust,

If that is all we want, we would not need any authentication at all.  We 
would merely care that Bob is the same Bob, not that he is the real Bob, 
which can be established by an un authenticated public key, as in in the 
Kong crypto system  

The proposed system  
provides that level of security.  A message that appears to be from a 
certain account can only come from someone who know the passphrase, 
regardless of whether you can see his face or not.

However much of the time we want to establish a slightly greater level of 
security, for example that Bob is the guy who works at our company, but is 
momentarily offsite, and not another Bob working for our competitor, we 
want to link a nym to a face.

For this purpose true name credential provide no real benefit, since it is 
quite hard for the original Bob to prove he is really Bob.  One effective 
way would get an unauthenticated public key signature from him face to 
face, (as in the PGP webn of trust) and then compare it with a later public 
key signature when he is communicating with us long distance, but ordinary 
people who are not crypto experts are incapable of doing this, and even 
crypto experts like myself are just too damn lazy to do it.

Looking at someone's face, and hearing his voice, is good enough in all 
common circumstances, and common circumstances means "where the customers are".

 --digsig
  James A. Donald
  6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
  lyvUXs8pXQDFRoZ09NXrsi3Xt/zA9HmLUF0BbCtD
  4YcNxd9Kd1ppHdM22MpekXnGFWTykfXJXy+MDZAYF

Re: A proposal for secure videoconferencing and video messaging over the Internet

[amanda]

On Wed, 26 Jul 2000, Eugene Leitl wrote:
> Clearly, you can maintain a secure connection to an anonymous party.
 
No you cannot. If Bob is anonymous then it is impossible for Alice to
know if her secure connection goes to Bob or Mitch. In the classic
man-in-the-middle attack Mitch impersonates Bob when talking to Alice and
he impersonates Alice when talking to Bob.

Did you read the literature on this stuff?

[Depends on what you mean by "anonymous". If the anonymous party has a
key he uses (i.e. the equivalent of a "nym") there is no problem at
all and no need for a CA either... --Perry]

> Authentication and security only touch shoulders when you're
> trusting the public key server

You are not supposed to trust key servers. It is the keys that you trust,
because they are signed by someone you trust (the CA or your WOT).


Amanda.

Re: A proposal for secure videoconferencing and video messaging over the Internet

[Eugene Leitl]

James A. Donald writes:

 > In real life situations where one wishes a conversation to be secure, are 
 > people most commonly authenticated by true name, or by face.
 
We're mixing several unrelated items in one pot here. One thing is
authentication, the other is securety. Authentication is when Alice
can prove with a very high probability that the current transaction is
being conducted with Bob, while in the past Alice or a party Alice
trusts has already had dealings with Bob. This creates a machinery for
maintaining a private (but publicable) list of identities which can
build trust, which is clearly useful to distinguish defectors from the
good guys. To best of my knowledge, authentication can be currently
only conducted with one-time pads (too inconvenient for large groups
of people) or public key cryptography (where in principle you could
put meddling black boxes downstream of public key servers, and perform
transparent key substitutions on the fly, or just spoof the IP address
of the keyserver(s), or just hack the key server, or remotely
compromise the local machine you're using).

Above does not say anything about whether this transaction is in
cypher or clear.

Of course you would typically want to conduct the session via a block
cypher channel, exchanging session keys either via one time pad or a
public key protocol. 

Clearly, you can maintain a secure connection to an anonymous
party. Authentication and securety only touch shoulders when you're
trusting the public key server (and the local machine, and the network
in between) to give you the right public keys which match advertised
identity. It would be obviously a good idea to generate a small set of
public/private key pair for every key server (putting them in the
keyring of well known privacy packages as default), and authenticate
each session with the key server. Another good idea is to conduct
random consistency checks against a pair of keyservers each residing
in different countries by yourself (of course this would make both the
privacy packages and the packets travelling between you and the world
more opaque), or someone who is widely trusted.
 
Anyone knows whether this is being done?

 > Think of every secure conversation you have had.  Did the participants know 
 > your true name?

A proposal for secure videoconferencing and video messaging over the Internet

[James A. Donald]

A proposal for secure videoconferencing and video messaging over the Internet
<http://catalog.com/jamesd/kong/secure_video.htm>

Personal presence service is going to be a protocol as widely used as http, 
and if we can get security into that protocol, it will result in widely 
deployed nyms, unlike our success in getting security into https.

With video, the authentication problem, which has always been the great 
barrier to the widespread use of crypto, goes away.

[Does it? In a few years, it should be possible to synthesize video in
real time... --Perry]