Re: [P2PSIP] Re: HIP pros and cons

Eric Rescorla <ekr@networkresonance.com> Fri, 21 December 2007 17:07 UTC

Return-path: <p2psip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5lL0-0003Tp-8j; Fri, 21 Dec 2007 12:07:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5lKy-0003Hi-Ss for p2psip@ietf.org; Fri, 21 Dec 2007 12:07:04 -0500
Received: from [74.95.2.173] (helo=romeo.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5lKy-0003nN-EH for p2psip@ietf.org; Fri, 21 Dec 2007 12:07:04 -0500
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 6A1C35081A; Fri, 21 Dec 2007 09:06:41 -0800 (PST)
Date: Fri, 21 Dec 2007 09:06:40 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Miika Komu <miika@iki.fi>
Subject: Re: [P2PSIP] Re: HIP pros and cons
In-Reply-To: <Pine.SOL.4.64.0712211143540.12362@kekkonen.cs.hut.fi>
References: <E1J0dHW-0005ik-OT@megatron.ietf.org> <Pine.SOL.4.64.0712080222070.16938@kekkonen.cs.hut.fi> <20d2bdfb0712100856q74c042d2y665964605fb37c71@mail.gmail.com> <Pine.SOL.4.64.0712121240120.24969@kekkonen.cs.hut.fi> <20071212160813.3863033C6D@delta.rtfm.com> <Pine.SOL.4.64.0712130903370.6449@kekkonen.cs.hut.fi> <20071213163033.6EE1433C72@delta.rtfm.com> <Pine.SOL.4.64.0712132245590.24299@kekkonen.cs.hut.fi> <20071213205251.548E933C6D@delta.rtfm.com> <Pine.SOL.4.64.0712140903370.8063@kekkonen.cs.hut.fi> <20071214145748.E37DF33C6D@delta.rtfm.com> <Pine.SOL.4.64.0712171802480.17561@kekkonen.cs.hut.fi> <20071217164438.38F0433C53@delta.rtfm.com> <Pine.SOL.4.64.0712181822460.27900@kekkonen.cs.hut.fi> <02e101c8419c$8aac4b30$640fa8c0@cis.neustar.com> <Pine.SOL.4.64.0712181938300.18063@kekkonen.cs.hut.fi> <200712181818.lBIIIWv9003612@romeo.rtfm.com> <Pine.SOL.4.64.0712211143540.12362@kekkonen.cs.hut.fi>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20071221170641.6A1C35081A@romeo.rtfm.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: p2psip@ietf.org
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Errors-To: p2psip-bounces@ietf.org

At Fri, 21 Dec 2007 11:51:02 +0200 (EET),
Miika Komu wrote:
> 
> On Tue, 18 Dec 2007, Eric Rescorla wrote:
> 
> Eric,
> 
> > At Tue, 18 Dec 2007 19:45:49 +0200 (EET),
> > Miika Komu wrote:
> >>
> >> On Tue, 18 Dec 2007, Brian Rosen wrote:
> >>
> >> Hi Brian,
> >>
> >> thanks for the feedback. It seems like the alternative b is mandatory for
> >> p2p-sip. Otherwise, then I don't see how you are going to avoid the use of
> >> cryptographic certificates without compromising dht identifier security
> >> and revocation.
> >>
> >> In alternative b, it is still possible to use host generated dht key
> >> identifiers.
> >
> > Again, not if you want to use them as the locations in the DHT,
> > because then you get chosen location attacks.
> 
> Yes but it costs. I don't see the difference here with host vs. enrollment 
> server generated keys because the end-host can enroll several times until 
> it is satisfied with the id. What makes the difference is the cost.

For the nth time, yes, but it requires a separate query to the 
enrollment server, which the enrollment server can throttle.
This doesn't work if the enrollment server lets the peer
propose the peer-id, since the peer can mount an offline 
attack on the location. Again, this is all in my slides from
YVR.


> Since I took the time to describe a detailed, step-by-step approach with 
> host generated identifiers, could you do the same with enrollment 
> server generated keys? Thanks.

I don't propose using enrollment server generated keys. I propose
separating cryptographic keys from peer-ids and using certificates
to bind them together. This is described in fairly complete detail
draft-bryan-p2psip-reload-02.


> P.S. If you want to reference some work, please give the authors and 
> titles to the publication or URL instead of some acronyms. Thanks.

I generally try to. If there's a particular one that wasn't clear
lemme know and I'll send you a full reference.

-Ekr


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip