Subject: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

From: seedorf at informatik.uni-hamburg.de (Jan Seedorf)
Date: Thu, 03 Aug 2006 12:15:17 +0200

Dear P2P-SIP folks,

for your interest: I have written a paper on how to protect the content stored in a P2P-SIP 
overlay (i.e. the binding of a SIP-URI to a location). My approach uses self-certifying SIP-
URIs (not to be confused with self-signed). More precisely, I suggest URIs that are computed 
from the hash of a public key. Only the owner of the corresponding private key can then sign 
messages regarding such a URI. Please note that this does not help anything to protect the 
availability of the overlay (e.g. against Sybil or Eclipse attacks) nor does it help in 
bootstrapping authentication (e.g. securely binding a real person to a public key or SIP-URI). 
What is does, however, is securely bind the identity used in the system (SIP-URI) to a public 
key. This (cryptographic) binding can be verified by anybody without relying on central 
authority. Thus, man-in-the-middle attacks on content are rendered infeasable.

The full (and long!) title of the paper is "Using Cryptographically Generated SIP-URIs to 
protect the Integrity of Content in P2P-SIP". You can download the paper at:
http://www.informatik.uni-hamburg.de/SVS/research/projects/voip/index.php

I have also a paper on P2P-SIP security to appear in the upcoming special issue of IEEE 
network on securing VoIP (Sept. 2006).

If you have any thoughts/questions/ideas on this, please let me know. I am looking forward to 
discussing self-certifyfing SIP-URIs.

Kind regards,
Jan Seedorf

-----------------------------
Jan Seedorf
Research Group Security in Distributed Systems (SVS)
Center for Distributed Information and Communication Systems (VIKS)
Dept. of Informatics, MIN Faculty, University of Hamburg
Vogt-Koelln-Str. 30, 22527 Hamburg, Germany
Tel.: +494042883-2325, Fax.:-2086
seedorf at informatik.uni-hamburg.de

"Life is not fair, but you should be"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060803/dc9eda40/attachment-0001.html

---

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Sat, 5 Aug 2006 10:55:50 -0700 (PDT)

--- Jan Seedorf <seedorf at informatik.uni-hamburg.de>

The idea in the paper is to use the text
representation of a truncated hash of the self signed
public key as "left side" component of the SIP URI.
The obvious problem there is the tension between
usability and safety. Long hashes are safer but hard
to read, while short hashes are easier to read and
remember but significantly easier to crack.

There is a good description of the possible
compromises in the "call sign" proposition by Huitema,
Cameron and Belanosh. It is available as EU patent
EP1612643,
http://v3.espacenet.com/textdoc?IDX=EP1612643&QPN=EP1612643.

-- Karst

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: kns10 at cs.columbia.edu (Kundan Singh)
Date: Mon, 07 Aug 2006 16:21:47 -0400

Hi Jan,

I read the paper with interest and liked the idea of using 
self-certifying identifiers in P2P-SIP.

The only disagreement I have is regarding conversion of hash value to a 
13-char user id using a second hash function, f,  because it increases 
the probability of hash collision to many folds. I think most modern 
P2P-SIP phones will have sophisticated phone books so that users don't 
have to type 30-char hash. Also, most I-am-yet-another-PSTN-phone style 
phones will use some kind of phone-extension_to_userid mapping, so users 
will enter only extensions or digits. Such mapping can follow the 
algorithm similar to the reverse of your function f, and can be done 
locally (either in the phone or the outbound proxy in an enterprise), so 
that the DHT still stores the key as full 128/160-bit hashed value of 
the public key.

Thanks.

Jan Seedorf wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Mon, 7 Aug 2006 17:00:16 -0400

I read the paper and it has many merits.

For one, uri generation is automated. That is very good.  But I'd like
to propose that the right hand side be part of the name game.

Some notes:

1. An alphanumeric 'left side' is slightly less readable than a long
telephone number.
    - Telephone numbers with 10-digit or more dialing are already
hard. Old problem.
    - The user reaction includes  'phone books' both on PC's and in
phones to dial by name.
    - Phonebooks are supposedly canonical.  Why couldn't P2PSIP
networks have them?
    - The phone book entry can also refer to a readable sip uri, like
an email address.
    - The email address could be used for confirmation, human to
human. The best way.
    - Email signatures could once again prove useful and have an
associated p2p uri.

2.  Hash collisions only really matter when the 'network' is large.
        - A small network could have a readable but still hard to guess hash.
        - The length could be shortened to a readable level.
        - Why guess when you can steal? That is the spammer's delight in SMTP.

3.  The right hand side of the URI matters greatly as it defines each network.
        - The RHS has to be trusted far more than the LHS.
        - The RHS must be able to verify that the LHS is true.
        - How to do this is an interesting problem.
        - IMHO the right hand side >must< be able to verify that the
left hand side is true.

5.  This is of course not a new problem
        - SMTP is an imperfect solution to this problem.
        - For an imperfect system it is staggeringly successful.
        - What works can be stolen, what doesn't can be avoided.
        - There is minimal baggage in this uri which is not the case for SMTP.
        - SMTP could very well benefit from this left hand side if
this gets broad adoption.

Some questions:

1. Does the RHS have to depend on DNS? Or could the RHS be overlay-generated?

2. In DNS-free P2P why can't the RHS >also< be a hash generated by a
trusted system?
    -  The RHS traditionally designates servers.
    -  P2P doesn't need servers.
    -  This means that the RHS can have a new meaning.
    -  Why not use a hash to automatically generate subgroups using the RHS?

The implications of 2 means that the 'starter node' is of critical
trust and importance.

What do you think?

Regards

Michael

---

From: bryan at ethernot.org (David A. Bryan)
Date: Tue, 8 Aug 2006 10:40:04 -0400

Although having a DNS resolvable name as an RHS is nice in many cases
(makes interop with existing SIP easier), it obviously doesn't have to
be. I've used an overlay name (just "name", not "name.com") before and
of course it works fine for an closed network. You can even subclass
it.

I'm a bit confused what you are proposing with a hash there however.
Would all members of the group have the same RHS still, or do you
propose they are unique per user, but related in some way because of
the hash?

Sounds intriguing. Just trying to get my head around it.

David

---

From: hannes.tschofenig at siemens.com (Tschofenig, Hannes)
Date: Tue, 8 Aug 2006 17:05:28 +0200

Hi David, 

for some time already everyone gets totally excited about using a hash of a public key for an identifier almost everywhere. The idea of computing a hash over a public key and then to use it as your identity (within P2P networks) was mentioned a couple of years ago.

Ciao
Hannes

> -----Urspr?ngliche Nachricht-----
> Von: p2p-sip-bounces at cs.columbia.edu 
> [mailto:p2p-sip-bounces at cs.columbia.edu] Im Auftrag von David A. Bryan
> Gesendet: Dienstag, 8. August 2006 16:40
> An: Michael Slavitch
> Cc: p2p-sip at cs.columbia.edu
> Betreff: Re: [p2p-sip] Self-certifying SIP-URIs for security 
> in P2P-SIP
> 
> > > > URIs (not to be confused with self-signed). More 
> precisely, I suggest URIs that are computed
> > > > If you have any thoughts/questions/ideas on this, 
> please let me know. I am looking forward to

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Tue, 8 Aug 2006 11:47:53 -0700

Who is supposed to host the "phonebooks" or mapping between self-certifying
URIs and user names?

Whoever the host is, he needs to be some kind of "central authority",
otherwise you can add a name "Peter Pan" on my behalf but associate it with
your public key (and hash) on your behalf.

Peter
----- Original Message -----
From: "Tschofenig, Hannes" <hannes.tschofenig at siemens.com>
To: "David A. Bryan" <bryan at ethernot.org>; "Michael Slavitch"
<slavitch at gmail.com>
Cc: <p2p-sip at cs.columbia.edu>
Sent: Tuesday, August 08, 2006 8:05 AM
Subject: Re: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

Hi David,

for some time already everyone gets totally excited about using a hash of a
public key for an identifier almost everywhere. The idea of computing a hash
over a public key and then to use it as your identity (within P2P networks)
was mentioned a couple of years ago.

Ciao
Hannes

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 9 Aug 2006 00:39:37 -0500

> your public key (and hash) on your behalf.

Peter has a point here.

Such a mechanism would seem to be useful for re-certification (I am  
the guy you talked to yesterday), but not so useful for initial  
operations. Of course, in some use cases, that's still a useful feature.

After all, there's no technical reason there can't be two (or more)  
people with different keys using the pseudonyms "Peter Pan" or "Dean  
Willis". But it would be nice to be able to tell them apart so you'd  
know which one you were actually talking to this time. Like "Is that  
the Dean Willis that's the head of the department, or that crazy guy  
from the IETF?"

--
Dean
aka PGP fingerprint  A09A7ADF

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Tue, 8 Aug 2006 23:14:40 -0700

Also, unless the mechanism could be manipulated to precisely generate
*predetermined* user IDs/URIs, can it make most telecos crazy because they
may rely on predetermined telephone numbers or prefixes to provide some IN
services like LNP or UN ("Unified Number" which merge all telephone numbers
of a user into one, eg. the "099" prefixes used in Taiwan CHT) ?

The unless above seemingly diverges from what the mechanism proposes,
because words "predetermined" and "random" seem completely opposite, if I
understand it correctly.

Of course, the concern is irrelevant if the mechanism targets at *hobby
networks* only.

Peter
----- Original Message -----
From: "Dean Willis" <dean.willis at softarmor.com>
To: "Peter Pan" <huang-ming.pan at comcast.net>
Cc: "Tschofenig, Hannes" <hannes.tschofenig at siemens.com>; "David A. Bryan"
<bryan at ethernot.org>; "Michael Slavitch" <slavitch at gmail.com>;
<p2p-sip at cs.columbia.edu>
Sent: Tuesday, August 08, 2006 10:39 PM
Subject: Re: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

---

From: hgs at cs.columbia.edu (Henning Schulzrinne)
Date: Wed, 9 Aug 2006 08:39:15 -0400

It is not clear to me that overloading the SIP URI with this type of  
certification is necessary or appropriate. What benefit does this  
offer compared to, say, S/MIME with self-signed keys?

---

From: hannes.tschofenig at siemens.com (Tschofenig, Hannes)
Date: Wed, 9 Aug 2006 14:59:52 +0200

Hi Henning, 

the property is that the URIs are self-certifying. The disadvantage is that you suddenly have to use hashes of public keys for user identification because you use those for routing. 

To make it easy for users you would then have to add another layer that allows to tie the real-world user identity to the keying material and, and, ....

Similarly to identity-based encryption I think it is a solution in search for a problem ...

Ciao
Hannes

> [mailto:p2p-sip-bounces at cs.columbia.edu] Im Auftrag von 
> Henning Schulzrinne
> Gesendet: Mittwoch, 9. August 2006 14:39
> An: P2P-SIP

---

From: hgs at cs.columbia.edu (Henning Schulzrinne)
Date: Wed, 9 Aug 2006 09:16:42 -0400

Given that SIP URIs don't just appear by themselves, but rather are  
part of a message, I'm just curious what advantage this self- 
certification offers. (SIP URIs do appear by themselves in other  
people's address books and on web pages, but there, it's just a  
string of opaque letters, regardless of whether they are self- 
certifying or not.)

On Aug 9, 2006, at 8:59 AM, Tschofenig, Hannes wrote:

> Hi Henning,
>
> the property is that the URIs are self-certifying. The disadvantage  
> is that you suddenly have to use hashes of public keys for user  
> identification because you use those for routing.
>
> To make it easy for users you would then have to add another layer  
> that allows to tie the real-world user identity to the keying  
> material and, and, ....
>

---

From: seedorf at informatik.uni-hamburg.de (Jan Seedorf)
Date: Wed, 09 Aug 2006 16:09:52 +0200

Consider the case of an intermediate node in a network P2P-SIP that is routing back (e.g. 
recursive routing) the response to a query. With self-certifying SIP-URIs this node can check 
whether the signature is valid for the URI without the need to have the corresponding 
certificate pre-stored. With S/MIME, if the body is signed with a self-signed private key which 
is send along, this intermediate node cannot verify that some other node has not changed the 
signature.

Still, Hannes has a point (as also specifically stated in the paper): the problem how to 
bootstrap authentication (certifying that the real user-identity belongs to a public-key or URI) 
is not solved with this. So in the case where the end-to-end recipient of a message has 
already a certificate of the sender there is indeed no benefit compmared to S/MIME. But in 
P2P-SIP there are many untrusted intermediates involved in routing messages, so it can be 
of benefit if an honest node can detect forged signatures along the way.

Hope that did explain some benefit...

Jan

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Wed, 9 Aug 2006 10:16:19 -0400

To me the benefits come from a clearly defined and standardized form
of automation for generating and assuring identity.  Bootstrapping
authentication can be solved by other techniques, however once there
is automated identity automated authentication will "somehow" follow.

M

---

From: seedorf at informatik.uni-hamburg.de (Jan Seedorf)
Date: Wed, 09 Aug 2006 16:17:24 +0200

Hi everybody,

thanks for the feedback on self-certifying SIP-URIs! In order not to open too many threads 
(although common on this mailing list :) ), I will try to answer all the comments in this mail 
(except the last comment from Henning Schulzrinne which I already answered). 

Kundan [suggested using the complete hash internally]: I agree with you. Internally using the 
complete hash is better. I was just trying to map this to a typeable URI, so users could actally 
type it in their phone, if necessary. In a highly secure use-case it might even be mandatory to 
use full 160-bit.

Michael [comments on right hand-side]: I have ignored the right hand-side so far, pretty much 
due to what David wrote: in an overlay it might just be the same for the whole overlay. Of 
course, there could also be an interconnection of P2P-SIP networks (see the work from 
Columbia). Here the right hand side is important and means DNS, I suppose. In such a case 
the right hand side could be useful for signing the real-identity (URI belongs to person) by 
some authority in each domain (as in the SIP identity-draft). Anyhow, in my opinion, in the 
"pure" P2P-SIP scenario without any servers the right hand-side is not necessary. If we have 
a trusted system signing the RHS, it is not pure P2P anymore, right?

Henry: "2. Presence is far more useful than any directory" I do not understand this? How can 
presence substitute a directory, where I can look up your URI?

Hannes [pointed out that self-certifying is not new]: I never claimed that self-certifying 
identities are new, it explicitly says that in the paper. What I am suggesting is that for P2P-
SIP there might be use-cases, where self-certifying identities make sense, mainly to prevent 
man-in-the-middle attacks on messages routed in the overlay.

Peter/Dean [phone book is central authority]: I absolutely agree on this with you. However, 
the overlay does not depend on this authority for operation. The purpose of the overlay is as 
follows (the same as with client-server SIP): "I give you a URI, you give me the location for 
that URI". Web-of-trust is an alternative to consider for a phonebook linking users with URIs.

Jan

---

From: seedorf at informatik.uni-hamburg.de (Jan Seedorf)
Date: Wed, 09 Aug 2006 16:23:07 +0200

Thought about this a little more, here a shorter, more precise answer:

With self-certifying URIs, _anybody_ (e.g. intermediates in routing) can verify the binding of a 
URI to a public key. With S/MIME the same is achieved, but only at the sender's and 
receiver's end, where a certificate that certifies this binding is stored locally.

Does that answer your question?

Jan

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Wed, 9 Aug 2006 10:40:59 -0400

"If we have a trusted system signing the RHS, it is not pure P2P
anymore, right?"

It's still peer to peer, only structured, and recursive, not flat.

---

From: hannes.tschofenig at siemens.com (Tschofenig, Hannes)
Date: Wed, 9 Aug 2006 16:48:13 +0200

Hi Jan, 

it is nice to verify that the binding of the URI to the public key if the URI is constructed in such a way. The open question is: What are the benefits of doing this compared to the disadvantages?

Btw, I noticed that a number of folks have used the idea of hashes of public keys as the identifiers for the lookup in P2P systems in the past. I wonder why their proposals have never received a lot of popularity either. 

Ciao
Hannes

PS: I previously mentioned that there needs to be a binding between the real-world identity and the public key hased in the URI. The more difficult part is that you use the hashed public key for discovering the other peer. Remembering hashes of public keys is not fully trival...
Providing another lookup service to resolve a searchable identity to the hash of a public key (or the public key) is needed. You might want to make this lookup secure since otherwise you could easily introduce mitm attacks.

> [mailto:p2p-sip-bounces at cs.columbia.edu] Im Auftrag von Jan Seedorf
> Gesendet: Mittwoch, 9. August 2006 16:23
> An: p2p-sip at cs.columbia.edu
> in P2P-SIP -difference to self-signed S/MIME
> 
> > >> otherwise you can add a name "Peter Pan" on my behalf 
> but associate
> > >> it with

---

From: seedorf at informatik.uni-hamburg.de (Jan Seedorf)
Date: Wed, 09 Aug 2006 18:11:16 +0200

Hi Hannes,

> it is nice to verify that the binding of the URI to the public key if the URI is constructed in such a way. The open question is: What are the benefits of doing this compared to the disadvantages?
I agree with you that this is the important question. My point of view: it might even be more 
convenient for users to type in such a cryptic URI than to set up a certificate for a callee. At 
least with webpages, handling certificates is a problem for the average user, so if it is 
encoded in the URI and the phone handles the rest this might be an advantage. Think about 
this: I give my sister my business card and tell her "this is my regular URI and printed below 
is the fingerprint of the corresponding public key, set this up on your phone" or I tell her "this 
is my secure URI (e.g. self-certifying), type it in and the phone will make sure that you will call 
me and nobody else". Also, the phone can bootstrap an encrypted media stream from this.

> PS: I previously mentioned that there needs to be a binding between
> the real-world identity and the public key hased in the URI.
Totally agree on this, but isn't this also the case with client-server SIP and not solved there 
either?

The more
> difficult part is that you use the hashed public key for discovering
> the other peer. Remembering hashes of public keys is not fully
> trival... Providing another lookup service to resolve a searchable
> identity to the hash of a public key (or the public key) is needed.
> You might want to make this lookup secure since otherwise you could
> easily introduce mitm attacks.
Yes, this is the big question. How to do this other than on a somewhat central server or a 
web of trust is not clear to me. DHT cannot not be used for fuzzy queries (e.g. "I know 
someone called Hannes from Siemens who does VoIP Security"). Otherwise one could use 
something like OpenDHT, which is - despite the name - a closed system from a security 
perspective.

Regards,
Jan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060809/e2b8a9e6/attachment-0001.html

---

From: seedorf at informatik.uni-hamburg.de (Jan Seedorf)
Date: Wed, 09 Aug 2006 18:15:20 +0200

Hi Henry,

> If spammers could look up my URI I would need to drop that VoIP service
> that has a directory service. What about yourself?
ok, I see what you mean. Maybe an online-phonebook is not such a good idea. URI-
harvesting worms will appear quickly, I agree. However, as Hannes pointed out: there must 
be a way to securely find the location of someone I want to call in the case I do not have a 
public key for that callee. Phonebook is just one option for this.

Jan

On 9 Aug 2006 at 8:30, Henry Sinnreich wrote:  

> Jan,
> 
> > Henry: "2. Presence is far more useful than any directory" I do not 
> > understand this? 
> > How can presence substitute a directory, where I can look up your URI?
> 
> If spammers could look up my URI I would need to drop that VoIP service
> that has a directory service. What about yourself?
> 
> Thanks, Henry
> 
> -----Original Message-----
> From: p2p-sip-bounces at cs.columbia.edu
> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Jan Seedorf
> Sent: Wednesday, August 09, 2006 7:17 AM
> To: p2p-sip at cs.columbia.edu
> > > > otherwise you can add a name "Peter Pan" on my behalf but
> associate
> > > > it with

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Wed, 09 Aug 2006 09:20:32 -0700

"Tschofenig, Hannes" <hannes.tschofenig at siemens.com> writes:
> for some time already everyone gets totally excited about using a
> hash of a public key for an identifier almost everywhere. The idea
> of computing a hash over a public key and then to use it as your
> identity (within P2P networks) was mentioned a couple of years ago.

Hannes is totally right here. The idea of using a public key (or hash
of a public key or truncated hash of a public key or whatever) is a
very natural one that comes up every few years (indeed, if you check
the videotape of the ad hoc meeting in YVR, you'll see the topic came
up there).

The advantage is that it's self certifying. The disadvantages are:

1. It's hard to remember because the strings need to contain enough
   entropy to make collisions and brute force attacks impractical.
   For a global sysem, this means identifiers need to be over
   64 bits, which is much longer than the average person can memorize
   easily. 

   For comparison, NANP 10 digit phone numbers have a maximum
   of 33 bits of entropy and in practice far less since most people
   deal with only a very small number of area codes so while that
   in principle contributes about 10 bits it really contributes more
   like 2.

2. They're not tied to the user's identity so it means if you
   want to look someone up by name (or even e-mail address!)
   you need some sort of secure directory.

In my experience, people usually eventually decide that these
disadvantages outweigh the advantages of this kind of system.

-Ekr

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Wed, 9 Aug 2006 12:30:22 -0400

> disadvantages outweigh the advantages of this kind of system.

Yes, but automated systems don't care.  Humans won't care if they
don't ever see the URI.  Let's not exclude the possibility from the
outset.

A serious question I have:

Would LHS | RHS hashed sip uris as described be a permitted use in P2PSIP?

If not, will there be a justification regarding why it's not a permitted use?

If it is a permitted use of a SIP URI it may be left as "one option of
many" including a DNS-based text uri..

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Wed, 09 Aug 2006 09:37:50 -0700

> don't ever see the URI.  Let's not exclude the possibility from the

I'm not excluding it--indeed, I'm the one who raised it back in YVR.
I'm just providing background to the discussion. That said, I think
most people take the problem of locators which can be printed on business
cards or read easily over the phone pretty seriously. The standard
approach here, as I indicated, is to use public keys or hashes as
your base identifier and then layer a directory service over top.
(cf. HIP).

> Would LHS | RHS hashed sip uris as described be a permitted use in P2PSIP?

Yeah, this is a natural progression, since it gives you uniqueness
without identity... I think I raised this one at YVR too :)

I would think so. After all, even if you want to represent things as
domain names, it's easy to do something like:

<hash>.p2p-sip-domain.com

Of course, this only helps so much, in two ways:

1. You need some convention to tell you which RHSes are self-certifying.
2. It doesn't improve memorizability that much unless there are only
   a relatively small number of RHSes.

> many" including a DNS-based text uri..

Right. 

-Ekr

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Wed, 9 Aug 2006 12:52:24 -0400

> your base identifier and then layer a directory service over top.

Yes indeed!

> without identity... I think I raised this one at YVR too :)

Heh. Good.

>    a relatively small number of RHSes.

You could embed it within RSS-like XML, which solves the stale-node
and stale directory  problem, you publish your own listings.  It is
that http uri which would be on the card.  The P2PSIP agent could then
figure out which is the one to use. Does anyone really imagine any new
end-user internet communications device not supporting RSS or HTTP?

> > many" including a DNS-based text uri..

But if at all possible let's not make the protocol 'optional', let's
do it right and define it clearly and simply at the right time. Let's
not turn P2PSIP identifiers into (ack) SNMP.

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Wed, 09 Aug 2006 09:58:01 -0700

> end-user internet communications device not supporting RSS or HTTP?

Right, but now we've just reduced this to a previously unsolved problem,
since it requires you to run a secure RSS service, as which point
why not just run your SIP proxy on the same machine?

-Ekr

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Wed, 9 Aug 2006 13:12:43 -0400

That's the thing: You don't have to run the service. You can publish
to a different one. The P2PSIP node just provides the data.  Blogs
aren't local to the publishing PC (or more often than not cellphone).
That authentication may be completely separate, and from a security
perspective it may be best to be that way.

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Wed, 09 Aug 2006 10:18:23 -0700

[Resent to list]

> perspective it may be best to be that way.

And why not simply contract with that person to run a SIP proxy?

-Ekr

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Wed, 9 Aug 2006 13:40:03 -0400

> And why not simply contract with a SIP proxy?

Because contracts require organizations and money.  Contracts are deterministic.

RSS is ad-hoc and can be published anywhere.

The target could be anywhere, a corporate directory, a national
provider's user database, a Google ad, a Myspace blurb, a blog.
Exploit flexibility.

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Wed, 09 Aug 2006 10:48:26 -0700

> RSS is ad-hoc and can be published anywhere.

Not if you want security.

-Ekr

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Wed, 9 Aug 2006 14:04:10 -0400

By publishing to the world security is moot.

The whole point of publishing is that everyone can see it.

The security issue is why I would have the directory system be
separatey, with different authentication.  Let HTTP auth and other
security systems take care of that.

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Wed, 09 Aug 2006 11:08:50 -0700

> The whole point of publishing is that everyone can see it.

There's more to security than confidentiality. In this case, the
relevant properties are integrity and data origin authentication.

> security systems take care of that.

HTTP Auth doesn't solve the problem. As a practical matter, you
end up having to host this data on an SSL/TLS server with a
real certificate, at which point we're well out of the realm of ad hoc.

-Ekr

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Wed, 09 Aug 2006 11:10:28 -0700

> real certificate, at which point we're well out of the realm of ad hoc.

In case the point isn't clear, we've just triumphantly reinvented
draft-ietf-sip-certs-01 in its original incarnation where an HTTPS
server was used instead of a SIP server.

-Ekr

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Wed, 9 Aug 2006 14:16:14 -0400

That might have stood a chance of broad adoption rather than
reinventing HTTPS in SIP servers.  The code exists and is in wide
accepted use.

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Wed, 09 Aug 2006 11:20:26 -0700

Well, maybe so, but the issue was extensively discussed and 
the current design was decided on. This isn't the place to 
revisit it.

-Ekr

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Mon, 7 Aug 2006 14:44:12 -0700

> But I'd like to propose that the right hand side be part of the name
game.

There is a lot of merit to this proposal, since P2P need not rely on the
DNS. There is other work along this line:

CoDoNS: Replacing the DNS with Peers:

www.cs.cornell.edu/People/egs/papers/codons-prenanog.pdf 

and also

http://www.cs.cornell.edu/People/egs/beehive/ 

Is there any interest in discussing this topic before making a
commitment to a standard proposal? Maybe shining some light on the path
ahead can prevent taking the wrong path in the first place :-)

Thanks, Henry 

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Michael Slavitch
Sent: Monday, August 07, 2006 2:00 PM
To: Kundan Singh
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

Some notes:

2.  Hash collisions only really matter when the 'network' is large.
        - A small network could have a readable but still hard to guess
hash.
        - The length could be shortened to a readable level.
        - Why guess when you can steal? That is the spammer's delight in
SMTP.

3.  The right hand side of the URI matters greatly as it defines each
network.

        - There is minimal baggage in this uri which is not the case for
SMTP.

Some questions:

1. Does the RHS have to depend on DNS? Or could the RHS be
overlay-generated?

    -  Why not use a hash to automatically generate subgroups using the
RHS?

What do you think?

Regards

Michael

> > protect the Integrity of Content in P2P-SIP". You can download the
paper at:
http://www.informatik.uni-hamburg.de/SVS/research/projects/voip/index.ph
p

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Mon, 7 Aug 2006 15:37:28 -0700

For what it is worth:

1. A distinction must be made between public VoIP directories (bad idea)
and enterprise directories (useful). In an enterprise directory, only
human display names should be perceived by the user.
 
2. Presence is far more useful than any directory.

As for phone numbers: Perish the thought :-)

Henry 

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Kundan Singh
Sent: Monday, August 07, 2006 1:22 PM
To: Jan Seedorf
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

Hi Jan,

Thanks.

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Tue, 8 Aug 2006 15:41:33 -0700

David,

> Just trying to get my head around it.
As mentioned, please see (or has my note not made it to the list:)

and also

Enjoy!

Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan
Sent: Tuesday, August 08, 2006 7:40 AM
To: Michael Slavitch
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

David

network.
overlay-generated?

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Wed, 9 Aug 2006 08:30:13 -0700

Jan,

Thanks, Henry

-----Original Message-----

Hi everybody,

thanks for the feedback on self-certifying SIP-URIs! In order not to
open too many threads 
(although common on this mailing list :) ), I will try to answer all the
comments in this mail 
(except the last comment from Henning Schulzrinne which I already
answered). 

Kundan [suggested using the complete hash internally]: I agree with you.
Internally using the 
complete hash is better. I was just trying to map this to a typeable
URI, so users could actally 
type it in their phone, if necessary. In a highly secure use-case it
might even be mandatory to 
use full 160-bit.

Michael [comments on right hand-side]: I have ignored the right
hand-side so far, pretty much 
due to what David wrote: in an overlay it might just be the same for the
whole overlay. Of 
course, there could also be an interconnection of P2P-SIP networks (see
the work from 
Columbia). Here the right hand side is important and means DNS, I
suppose. In such a case 
the right hand side could be useful for signing the real-identity (URI
belongs to person) by 
some authority in each domain (as in the SIP identity-draft). Anyhow, in
my opinion, in the 
"pure" P2P-SIP scenario without any servers the right hand-side is not
necessary. If we have 
a trusted system signing the RHS, it is not pure P2P anymore, right?

understand this? How can 

Hannes [pointed out that self-certifying is not new]: I never claimed
that self-certifying 
identities are new, it explicitly says that in the paper. What I am
suggesting is that for P2P-
SIP there might be use-cases, where self-certifying identities make
sense, mainly to prevent 
man-in-the-middle attacks on messages routed in the overlay.

Peter/Dean [phone book is central authority]: I absolutely agree on this
with you. However, 
the overlay does not depend on this authority for operation. The purpose
of the overlay is as 
follows (the same as with client-server SIP): "I give you a URI, you
give me the location for 
that URI". Web-of-trust is an alternative to consider for a phonebook
linking users with URIs.

Jan

associate

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Fri, 11 Aug 2006 06:26:59 -0700

>64 bits, which is much longer than the average person can memorize

This is where PRESENCE comes in so handy. The presence icon can hide
underneath all the contact addresses of my friends, and I never have to
remember all their URIs or phone numbers. Or big hashed identifiers.

Thanks, Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Eric Rescorla
Sent: Wednesday, August 09, 2006 11:21 AM
To: Tschofenig, Hannes
Cc: p2p-sip at cs.columbia.edu; David A. Bryan
Subject: Re: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

-Ekr

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Fri, 11 Aug 2006 21:48:59 -0700

Yah - 100% agree with Peter - this whole approach to self  
certification is one of the things I have brought up many times about  
why p2p voice is not the same as file sharing and why we will want  
technology that is sometimes a little different.

On Aug 8, 2006, at 11:47 AM, Peter Pan wrote:

> hash of a

---

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Sun, 13 Aug 2006 22:05:58 -0700 (PDT)

> remember all their URIs or phone numbers. Or big

But then, you need to find the URI of your friend, in
a human-friendly peer-to-peer way. Currently, we do
that by copying information from business cards,
spelling it over the phone, maybe writing it down from
memory on a restaurant's napkin. 

If I remember correctly the untrained individual can
keep about 7 digits in memory. Assuming base 32,
that's 35 bits. We could perhaps teach people to
remember a sequence of 8 or 9 letters, with some
training. But that is still only 40 or 45 bits.

The classic solution is to create the identifier by
hashing a key and a "salt", and to choose the salt
very well, so the hash ends with a large number of
zeros. Suppose for example a 45 bits identifier, and a
salt chosen to provide 40 zeroes. That is arguably as
hard to break as an 85 bits hash, possibly OK for some
applications.

But that is not the end of it. You also have to deal
with collisions. Suppose a population of 1 billion P2P
SIP users. If you pick a random 45 bit ID, you have a
risk of collision of 2^-15. If you put it another way,
an attacker would only need 2^15 trials before being
able to spoof at least one random user. 

That does not mean we cannot use the scheme. It just
means we have to somehow solve the collision issue.
One possible way is to let users choose a mnemonic
name, e.g. "peter.pan". Then, we can hash this name,
the public key and the salt, so the numeric identifier
is tied to both the name and the key. The
self-verifiable P2P SIP identifier would then be
something like "peter.pan.3KA-DM1-H89 at p2psip.net".

Combining the name with the identifier dramatically
reduces the risk of collision. The name is longer, but
it is composed of two components that can be memorized
separately, spelled over the phone, etc. 

-- Karst

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Sun, 13 Aug 2006 22:23:59 -0700

Karst Bjorgson <karstbj at yahoo.com> writes:
> that's 35 bits.

If by "in memory" you mean "in short term memory", sure.  It takes
most people effort to memorize a 7-digit number, though.

> hard to break as an 85 bits hash, possibly OK for some

Creating a preimage which hashes to a value with 2^40 low-order zeros
takes approximately 2^40 hash operations. My laptop does 70,000 SHA-1
operations per second. That's approximately 180 days of computation to
generate a key. Even 25 bits is about 8 minutes, and of course 
my laptop is a lot faster than your average cell phone.

-Ekr

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Sun, 13 Aug 2006 22:31:01 -0700

> my laptop is a lot faster than your average cell phone.

Oops. Dropped a digit there... That's 700,000, so 18 days and 
about 1 minute.

-Ekr

---

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Sun, 13 Aug 2006 22:42:31 -0700 (PDT)

> my laptop is a lot faster than your average cell

I guess it depends on the hash function and its
implementation. In my own tests, I was using MD5 and
getting 24 bits in about 15 seconds on my laptop.

But the whole idea is based on cost differentials. If
the published part is 45 bits, and if I spend T
seconds of CPU to obtain a "good hash", then the
attacker will need to spend 2^45 times that. Even if
we assume that the attacker controls a 1,000,000
strong botnet, each bot will need to spend 2^25 times
the time I spent on my computer. If I am willing to
spend a minute, each bot will have to compute for 60
years. If I am willing to spend an hour, each bot will
need to spend 36 centuries.

Of course, the time is only spent when computing the
salt for the first time. After that, verification
takes a single pass.

-- Karst

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Mon, 14 Aug 2006 04:30:43 -0700

> getting 24 bits in about 15 seconds on my laptop.

Yes, but what makes you think that it's going to be hard
to compute partial preimages in MD5 for the next 5 years?

> need to spend 36 centuries.

Yes, I appreciate all this, but most of the work here
is being done by the 2^45 bits of variable value and 
not the 2^25 bits or so of fixed value. This is true
for key stretching/iteration schemes in general where
there is a wide disparity in compute power between the
attacker and defender and therefore the defender can't 
really afford to do much stretching.

-Ekr

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Mon, 14 Aug 2006 07:22:32 -0700

Karst,

I don't understand all the complexities that you describe.
As a proof, try and add a buddy to your Skype buddy list and see how
simple that is. You will also see the other contact addresses the other
party is willing to share, but you don't have to remember any of them.

Thanks, Henry

-----Original Message-----
From: Karst Bjorgson [mailto:karstbj at yahoo.com] 
Sent: Monday, August 14, 2006 12:06 AM
To: Henry Sinnreich; EKR; Tschofenig, Hannes
Cc: p2p-sip at cs.columbia.edu; David A. Bryan
Subject: Re: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

-- Karst

---

From: br at brianrosen.net (Brian Rosen)
Date: Mon, 14 Aug 2006 10:42:21 -0400

But Henry, that only works because there is this central database that Skype
runs and people trust.  It's the part of Skype that is definitely not peer
to peer.

We have very nice centralized directory systems.  I thought we were not
trying to depend on centralized systems.

Karst describes a mechanism that doesn't need anything centralized.  I'm not
sure I like the proposal, but it fits what I think of as p2p sip.

Brian

> From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-
> bounces at cs.columbia.edu] On Behalf Of Henry Sinnreich
> Sent: Monday, August 14, 2006 10:23 AM
> To: Karst Bjorgson; EKR; Tschofenig, Hannes

---

From: hannes.tschofenig at siemens.com (Tschofenig, Hannes)
Date: Mon, 14 Aug 2006 16:50:04 +0200

Hi Henry, 

Skype does not use hashes of public keys as identities but rather unstructured strings. 

Try to find someone if the identity is a hash of a public key and you don't know it.

Ciao
Hannes

> Von: Henry Sinnreich [mailto:hsinnrei at adobe.com] 
> Gesendet: Montag, 14. August 2006 16:23
> An: Karst Bjorgson; EKR; Tschofenig, Hannes
> Betreff: RE: [p2p-sip] Self-certifying SIP-URIs for security 
> in P2P-SIP
> 
> Karst,
>

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Mon, 14 Aug 2006 07:54:23 -0700

Brian,

The customer DB is one of the few servers that P2P systems like Skype
use.

This is still a far cry from the labyrinth of CS systems we see today.

I still believe in PRESENCE!  Do you?

Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Brian Rosen
Sent: Monday, August 14, 2006 9:42 AM
To: Henry Sinnreich; 'Karst Bjorgson'; 'EKR'; 'Tschofenig, Hannes'
Cc: p2p-sip at cs.columbia.edu; 'David A. Bryan'
Subject: Re: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

But Henry, that only works because there is this central database that
Skype
runs and people trust.  It's the part of Skype that is definitely not
peer
to peer.

Karst describes a mechanism that doesn't need anything centralized.  I'm
not
sure I like the proposal, but it fits what I think of as p2p sip.

Brian

---

From: hannes.tschofenig at siemens.com (Tschofenig, Hannes)
Date: Mon, 14 Aug 2006 17:07:55 +0200

Hi all, 

I am wondering whether a document exists that outlines the scope of the work. What type of functionality do you assume to be centralized and what should be distributed.

Ciao
Hannes

> Gesendet: Montag, 14. August 2006 16:54
> An: Brian Rosen; Karst Bjorgson; EKR; Tschofenig, Hannes

---

From: br at brianrosen.net (Brian Rosen)
Date: Mon, 14 Aug 2006 11:46:56 -0400

Not yet, but we are working towards it.  Our first step is to define a
charter, and certainly scope like this would be something considered in the
charter.

Brian

> From: Tschofenig, Hannes [mailto:hannes.tschofenig at siemens.com]
> Sent: Monday, August 14, 2006 11:08 AM
> To: Henry Sinnreich; Brian Rosen; Karst Bjorgson; EKR
> Subject: AW: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP
> 
> Hi all,
> 
> I am wondering whether a document exists that outlines the scope of the
> work. What type of functionality do you assume to be centralized and what
> should be distributed.
> 
> Ciao
> Hannes
>

---

From: br at brianrosen.net (Brian Rosen)
Date: Mon, 14 Aug 2006 11:59:08 -0400

Yes, I believe in presence.  I'm not sure p2psip implies a centralized
presence server.  So far, you don't use a presence server to DISCOVER an
AoR; you have it first, and you subscribe to presence.  You can use presence
to discover a contact address, and of course, that might result in any kind
of URI, with any kind of LHS and RHS.  Presence does not have to be
centralized, but can be peer-to-peer just as voice, video or text sessions
can be.  I was making a leap that p2p sip implied that p2p presence worked,
at least for the conveyance of presence information to a watcher using the
sip protocol.

It IS hard to get away without some centralized, or at least well known
things which can be used to discover the rest of the infrastructure.  I
think trust is pretty hard to create without some centralized, or trusted
party for example.  However, the idea that you have to have some kind of
centralized address book, or centralized AoR to DHT credential translation
strikes me as not a good starting point.  If that is an unsolveable problem,
we may get backed into such a circumstance.

Are others just assuming a centralized user database?

Brian

> From: Henry Sinnreich [mailto:hsinnrei at adobe.com]
> Sent: Monday, August 14, 2006 10:54 AM
> To: Brian Rosen; Karst Bjorgson; EKR; Tschofenig, Hannes
> Subject: RE: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP
> 
> Brian,
>

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 14 Aug 2006 09:03:15 -0700

In my opinion, bootstraping AA needs be centralized.

All others should be distributed with the best efforts.

Peter
----- Original Message -----
From: "Brian Rosen" <br at brianrosen.net>
To: "'Tschofenig, Hannes'" <hannes.tschofenig at siemens.com>; "'Henry
Sinnreich'" <hsinnrei at adobe.com>; "'Karst Bjorgson'" <karstbj at yahoo.com>;
"'EKR'" <ekr at networkresonance.com>
Cc: <p2p-sip at cs.columbia.edu>; "'David A. Bryan'" <bryan at ethernot.org>
Sent: Monday, August 14, 2006 8:46 AM
Subject: Re: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

Brian

---

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Mon, 14 Aug 2006 12:37:30 -0400

Inline [RRR].

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Brian Rosen
Sent: Monday, August 14, 2006 11:59 AM
To: 'Henry Sinnreich'; 'Karst Bjorgson'; 'EKR'; 'Tschofenig, Hannes'
Cc: p2p-sip at cs.columbia.edu; 'David A. Bryan'
Subject: Re: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

...

[RRR] Not yet, unless it is extremely hard to get solution in p2p-sip.

Brian

---

From: bryan at ethernot.org (David A. Bryan)
Date: Mon, 14 Aug 2006 15:12:10 -0400

In my thoughts, I certainly haven't assumed a centralized user
database, and it isn't needed at least in many deployments. We are
doing presence right now in a purely P2P way.

The one place I think a central server is very useful (although not
essential, depending on the purpose of the system) is as a certificate
server. Having an entity that can issue certificates helps with both
identity and security.

Bootstrap nodes are another that are nice if they are persistent, but
of course that isn't really a central server, just a "persistent"
peer, really.

David

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Mon, 14 Aug 2006 12:47:26 -0700

David,

I fully agree with your summary about the need or otherwise for a
central customer database.

Besides issuing certificates for security reasons, such a server is also
required to enroll users, make sure of their civic identity by some
means and last but not least, getting the payment for the service,
depending on the business model.

There is also a technical reason: Partial searches cannot be
accomplished in DHT. You could not look me up knowing only the last name
or part of the name. Sorry to give Skype again as an example, it allows
doing a partial query and presents several choices, actually just like
Google does (but without advertisements).

Woops! I may just have discovered a new revenue source for Skype :-)

Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan
Sent: Monday, August 14, 2006 2:12 PM
To: Brian Rosen
Cc: p2p-sip at cs.columbia.edu; Tschofenig,Hannes
Subject: Re: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

David

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 14 Aug 2006 13:10:33 -0700

Any DHT can do partial searches thru flooding, at least.

Skype could be starved if it lived on searches with ads.

Hard for me to learn the purposes why people would diligently search for
full identities of others.

Peter
----- Original Message -----
From: "Henry Sinnreich" <hsinnrei at adobe.com>
To: "David A. Bryan" <bryan at ethernot.org>; "Brian Rosen" <br at brianrosen.net>
Cc: <p2p-sip at cs.columbia.edu>; "Tschofenig,Hannes"
<hannes.tschofenig at siemens.com>
Sent: Monday, August 14, 2006 12:47 PM
Subject: Re: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Mon, 14 Aug 2006 16:48:15 -0500

> full identities of others.

It's usually the other way around. I know all sorts of stuff about  
Henry (including his "civic identity"), but I don't know his P2PSIP  
identity. How can I discover what this is?

That's the sort of thing that seems to require a centralized component.

And even if his identity is self-certified, I can at least use it to  
secure the channel and authenticate future connections, once I've  
used in-band "human" means to convince myself I found the right Henry.

--
Dean

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 14 Aug 2006 15:19:57 -0700

Sorry, I should have said "Hard for me to learn the purposes why people
would diligently search for full identities of others after their identities
have been learned and saved on the first search".

Peter
----- Original Message -----
From: "Dean Willis" <dean.willis at softarmor.com>
To: "Peter Pan" <huang-ming.pan at comcast.net>
Cc: "Henry Sinnreich" <hsinnrei at adobe.com>; "David A. Bryan"
<bryan at ethernot.org>; "Brian Rosen" <br at brianrosen.net>;
<p2p-sip at cs.columbia.edu>; "Tschofenig, Hannes"
<hannes.tschofenig at siemens.com>
Sent: Monday, August 14, 2006 2:48 PM
Subject: Re: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Mon, 14 Aug 2006 15:20:25 -0700

Peter,

> Any DHT can do partial searches thru flooding, at least.

Can you point to any reference on this?

My understanding is the hash in the DHT represents the complete name,
such as <huang-ming-pan>. A search for <huang> would not give any useful
results. Is this correct? Why/how would flooding change this?

Thanks, Henry

-----Original Message-----
From: Peter Pan [mailto:huang-ming.pan at comcast.net] 
Sent: Monday, August 14, 2006 3:11 PM
To: Henry Sinnreich; David A. Bryan; Brian Rosen
Cc: p2p-sip at cs.columbia.edu; Tschofenig,Hannes
Subject: Re: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

Peter
----- Original Message -----
To: "David A. Bryan" <bryan at ethernot.org>; "Brian Rosen"
<br at brianrosen.net>

> > presence server.  So far, you don't use a presence server to
DISCOVER
> an
> > to discover a contact address, and of course, that might result in
any
> kind
> > at least for the conveyance of presence information to a watcher
using
> the
> > party for example.  However, the idea that you have to have some
kind
> of
> > > We have very nice centralized directory systems.  I thought we
were
> > > Karst describes a mechanism that doesn't need anything
centralized.
> I'm
> > > > simple that is. You will also see the other contact addresses
the
> > > other

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 14 Aug 2006 16:01:49 -0700

Sorry, Henry.

No, I cannot.

The "can do" is per my confidence in implementing the capability to flood a
DHT with wildcard matching msgs like "MATCH <huang*>". Those flooded nodes
which own or have ever learned any identity with prefix "huang" can respond
then. Flooding needs no hash.

According to my observation of program behavior and msg trace I guess Skype
also uses flooding for its partial name search.

Peter
----- Original Message -----
From: "Henry Sinnreich" <hsinnrei at adobe.com>
To: "Peter Pan" <huang-ming.pan at comcast.net>; "David A. Bryan"
<bryan at ethernot.org>; "Brian Rosen" <br at brianrosen.net>
Cc: <p2p-sip at cs.columbia.edu>; "Tschofenig,Hannes"
<hannes.tschofenig at siemens.com>
Sent: Monday, August 14, 2006 3:20 PM
Subject: RE: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

Peter,

Thanks, Henry

-----Original Message-----
From: Peter Pan [mailto:huang-ming.pan at comcast.net]
Sent: Monday, August 14, 2006 3:11 PM
To: Henry Sinnreich; David A. Bryan; Brian Rosen
Cc: p2p-sip at cs.columbia.edu; Tschofenig,Hannes
Subject: Re: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

Peter

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Mon, 14 Aug 2006 16:34:31 -0700

Peter,

>Those flooded nodes which own or have ever learned any identity with
prefix >"huang" can respond then.

Peer nodes may know only the hash of the complete name. 
They have no knowledge of what the name may be, since the hash is
irreversible. 
As a consequence, peer nodes cannot know there is a "huang" contained in
the hashed name.

Doing a dictionary attack on a DHT layer (what you call flooding) is
rather a hostile action, then a normal query. And for the reasons
mentioned above, would not work anyway.

This brings us back to the initial point, that with DHT technology,
partial searches require a centralized database of the conventional
type. Which is not so bad since it is useful for other purposes:
Enrollment, identity, monetizing and downloads. 

This is however what any web merchant would require as well, for selling
anything on the web. Or for giving things away for free, such as open
source software or white papers for interesting prospects.

Thanks, Henry

-----Original Message-----
From: Peter Pan [mailto:huang-ming.pan at comcast.net] 
Sent: Monday, August 14, 2006 6:02 PM
To: Henry Sinnreich; David A. Bryan; Brian Rosen
Cc: p2p-sip at cs.columbia.edu; Tschofenig,Hannes
Subject: Re: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

Sorry, Henry.

No, I cannot.

The "can do" is per my confidence in implementing the capability to
flood a
DHT with wildcard matching msgs like "MATCH <huang*>". Those flooded
nodes
which own or have ever learned any identity with prefix "huang" can
respond
then. Flooding needs no hash.

According to my observation of program behavior and msg trace I guess
Skype
also uses flooding for its partial name search.

Peter
----- Original Message -----

Peter,

Thanks, Henry

-----Original Message-----
From: Peter Pan [mailto:huang-ming.pan at comcast.net]
Sent: Monday, August 14, 2006 3:11 PM
To: Henry Sinnreich; David A. Bryan; Brian Rosen
Cc: p2p-sip at cs.columbia.edu; Tschofenig,Hannes
Subject: Re: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

Peter

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 14 Aug 2006 17:58:56 -0700

Hi, Henry.

I cannot quite understand your worries.

Why your address book contains only hashes of your buddies but not their
full names? What user information do you show on your present agent?

Hostility of flooding search can be alleviated by enforcing msg time-to-live
or sort of reputation/credit auditing.

Isn't a dictionary attack on centralized database more hostile?

Diligent searchers are often suspicious, IMO. Their search frequency should
be modulated.

Controlled flooding is not so awful la. GET/PUT operations on some types of
DHTs seem like (k-way controlled) miniatures of msg flooding.

Peter

----- Original Message -----
Sent: Monday, August 14, 2006 4:34 PM

Peter,

Thanks, Henry

-----Original Message-----
From: Peter Pan [mailto:huang-ming.pan at comcast.net]
Sent: Monday, August 14, 2006 6:02 PM
To: Henry Sinnreich; David A. Bryan; Brian Rosen
Cc: p2p-sip at cs.columbia.edu; Tschofenig,Hannes
Subject: Re: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

Sorry, Henry.

No, I cannot.

Peter
----- Original Message -----

Peter,

Thanks, Henry

-----Original Message-----
From: Peter Pan [mailto:huang-ming.pan at comcast.net]
Sent: Monday, August 14, 2006 3:11 PM
To: Henry Sinnreich; David A. Bryan; Brian Rosen
Cc: p2p-sip at cs.columbia.edu; Tschofenig,Hannes
Subject: Re: [p2p-sip] Self-certifying SIP-URIs for security in P2P-SIP

Peter

---

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Mon, 14 Aug 2006 20:42:52 -0700 (PDT)

> to compute partial preimages in MD5 for the next 5

The time to compute the preimages will probably be
halved for each round of Moore's law. So, it means
that one needs to add an extra bit for each 18 month
of expected life time of the identifier.

-- Karst

---

From: ekr at networkresonance.com (Eric Rescorla)
Date: Tue, 15 Aug 2006 06:44:21 -0700

> of expected life time of the identifier.

That's assuming there's no fast analytic attack on MD5.
That doesn't seem like that safe an assumption at this
particular moment. 

Yes, I realize that this is a side issue. I'm merely
pointing out that you need to use SHA-1 as your basis
for speed comparison, not MD5.

-Ekr

---

From: br at brianrosen.net (Brian Rosen)
Date: Tue, 15 Aug 2006 10:00:11 -0400

I think we are off the deep end.

I think we should restrict our work to how you create sessions with
identities you know, and not work on the problem of searching for identity
given some other information.

For example, there is no defined mechanism in sip to search for an AoR
knowing some part of a name.

I agree that you need some trusted authority to create credentials.  I'm not
sure that we need much else centralized.  We need discovery mechanisms (for
"super nodes, as a example), but they can be at least somewhat distributed.

I'm not worried about creating anything special for charging mechanisms

Brian

> Sent: Monday, August 14, 2006 7:35 PM
> To: Peter Pan; David A. Bryan; Brian Rosen

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Tue, 15 Aug 2006 10:30:28 -0400

> given some other information.

This is a good suggestion for the scope of the first version.

Thanks.

Eunsoo

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Tue, 15 Aug 2006 09:55:41 -0500

From: "Eunsoo Shim" <eunsoo at research.panasonic.com>

> This is a good suggestion for the scope of the first version.

Agree with Brian and with Eunsoo.

>> knowing some part of a name.

... the key words in this sentence being "in SIP" - I think that means "nor 
should there be". That doesn't mean that someone, somewhere, can't be 
thinking about this and proposing such a mechanism, just that we wouldn't 
gate on that happening here.

As Henry pointed out, it's nice to have a search mechanism in Skype, and if 
someone wanted to define such a thing for other networks, that would be 
great. Since I had the privilege of looking up someone in a different 
language/character set last week, I can verify that at least a little 
internationalization work needs to happen before this will work well :-)

>> "super nodes, as a example), but they can be at least somewhat 

Thanks,

Spencer

---

From: bryan at ethernot.org (David A. Bryan)
Date: Wed, 16 Aug 2006 12:18:34 -0400

At least as far as this pertains to the upcoming BOF, I fully agree
this would be useful, and certainly is something people are interested
in long term, but I think we agreed at the ad-hoc that it was a bit
more to bite off right now than we can chew, and was something that we
didn't want to include in the initial charter.

David

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Wed, 16 Aug 2006 09:29:55 -0700

My apology folks for not focusing first on getting the BOF through
successfully.

I can table the enrollment server and crypto key distribution for P2P
SIP later on, as David says.

Thanks, Henry

-----Original Message-----
Sent: Wednesday, August 16, 2006 11:19 AM
To: Spencer Dawkins

David

On 8/15/06, Spencer Dawkins <spencer at mcsr-labs.org> wrote:
> >> I agree that you need some trusted authority to create credentials.
I'm
> >> not
> >> sure that we need much else centralized.  We need discovery
mechanisms
> >> (for