Subject: [p2p-sip] Review of draft-bryan-sipping-p2p-02

From: dromasca at avaya.com (Romascanu, Dan (Dan))
Date: Mon, 13 Mar 2006 17:06:30 +0200

Yes, but this brings me to the charter proposal and to the fact that
security is very vaguely dealt with in the charter. 

In assumptions we say: 

5. The level of authenticity of identity will vary by the peer
   association group. However, the working group will define at least
   one mechanism that will provide assertion of identity having
   strength equivalent to that provided by the "SIP Identity
   Mechanism" RFC, perhaps by reusing some or all of the mechanism of
   that RFC.

And then, the scope of the work is defined 

While ensuring:

1. Security is addressed in these systems.

It is not clear where the security requirements are defined beyond what
is presented in the assumptions, and in the absence of requirements I am
afraid that we may continue this type of discussions at later phases. 

Regards,

Dan

> -----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, March 13, 2006 4:51 PM
> To: EKR
> Cc: p2p-sip at cs.columbia.edu
> Subject: Re: [p2p-sip] Review of draft-bryan-sipping-p2p-02
> 
> Just to make sure everyone remembers, this draft isn't really 
> intended to be standardized in any way as it stands anyway 
> (we say that in the intro, and I've mentioned that in all my 
> talks), instead it was proposed as a "hey, here is how we 
> might make this work, this is what we are experimenting with" 
> strawman, and the current iteration is changes as a result of 
> lessons learned in implementation, so I will be the first to 
> agree with Eric that as it stands this ain't even remotely 
> close to something to consider for standardization. It was 
> put out as a strawman to shoot at to come up with something 
> useful, so looks like it is working!
> 
> The security section in particular is really old (most of it 
> from the -00 draft that Cullen and I wrote over a year ago), 
> and hasn't been updated much since we largely have been 
> working with the message passing in our coding and wanted to 
> share some things we thought improved that work. I've 
> actually had some conversations (several with Eric, actually) 
> where using centrally issued certificates (possibly rate 
> limited somehow), and storing fully verifiable certificate 
> chains in the overlay was suggested, and in fact seem the 
> only way to truly secure something like this. We are likely 
> to look toward something like that for the next iteration. I 
> realize only addresses *part* of Eric's concerns anyway, but 
> I just want everyone to be clear about what this draft is 
> (strawman) and what it isn't (something that in anything 
> resembling its current form is being suggested as a standard).
> 
> Heck, I'm hoping we get a new WG which can define better 
> requirements and architecture from many more sources and then 
> we can get some folks working on a better (and far more 
> secure) idea for how to get this done.
> 
> --David
> 
> On 3/13/06, Eric Rescorla <ekr at networkresonance.com> wrote:
> > "David Barrett" <dbarrett at quinthar.com> writes:
> >
> > >> -----Original Message-----
> > >> From: Eric Rescorla [mailto:ekr at networkresonance.com]
> > >>
> > >> "David Barrett" <dbarrett at quinthar.com> writes:
> > >> >
> > >> > Given that a secure DHT is an unsolved problem, and given the 
> > >> > IETF only deals with solved problems, should we:
> > >> >
> > >> > 1) Standardize the best practices today, despite their 
> insecurity.
> > >> >
> > >> >    -- OR --
> > >> >
> > >> > 2) Wait until a secure DHT has been invented and reconvene.
> > >> >
> > >> > I vote for #1.  I certainly don't vote for the unstated #3:
> > >> "Simultaneously
> > >> > invent and standardize a new variant of DHT that is 
> secure (for 
> > >> > some definition of 'secure')."
> > >>
> > >> There's a point below which the security of the system is so bad 
> > >> that it shouldn't be standardized. The question is 
> whether that's 
> > >> the case here.
> > >
> > > That's a fair question, how would you answer it?
> > >
> > > If your answer is "yes, DHTs are so insecure that 
> standardization is 
> > > pointless" then would you advise that we dissolve and 
> reconvene later?
> > >
> > > If your answer is "no, DHTs aren't so insecure so as to make 
> > > standardization pointless" then would you advise that we 
> continue on our current path?
> > >
> > > Or do you have another answer such as "yes, the DHT we're 
> currently 
> > > discussing is so insecure that standardization is pointless, and 
> > > therefore we should <insert alternate plan>."
> >
> > As far as I can tell, the combined system described in this 
> document 
> > is so insecure that it should not be standardized. There 
> may be some 
> > hybrid system (e.g., along the lines of that described by Cox et al 
> > <http://www.pdos.lcs.mit.edu/chord/papers/ddns.pdf>), most 
> likely with 
> > externally verified authentication that would be worth 
> standardizing.
> >
> > -Ekr
> >