Re: An attack on paypal

2003-06-13 Thread John Gilmore
> as in previous observations having a domain name owner register their > public key in the internet registry (domain name infrastructure or > ip-address registery) starts to lesson the requirement for having SSL > domain certificates. Yes; this is why (I think) VeriSign bought Network Sol

Re: SDSI/SPKI background

2003-06-13 Thread Stefan Mink
Hi Carl, On Wed, Jun 11, 2003 at 09:56:12PM -0700, Carl Ellison wrote: > There's one draft that should have gone on to RFC, but people were > using it from the draft instead. It's my fault that we left it at > that stage and didn't publish the RFC. That's still on my list of > things to do :-)

Re: Session Fixation Vulnerability in Web Based Apps

2003-06-13 Thread James A. Donald
-- On 12 Jun 2003 at 16:25, Steve Schear wrote: http://www.acros.si/papers/session_fixation.pdf Wow. This flaw is massive, and the biggest villain is the server side code created for Apache. When you login to your bank, your e-gold account, your stockbroker, or your domain registrar, someo

Re: Session Fixation Vulnerability in Web Based Apps

2003-06-13 Thread tom st denis
--- "James A. Donald" <[EMAIL PROTECTED]> wrote: > -- > On 12 Jun 2003 at 16:25, Steve Schear wrote: > http://www.acros.si/papers/session_fixation.pdf > > Wow. > > This flaw is massive, and the biggest villain is the server > side code created for Apache. You really lack some fundamental u

RE: Keyservers and Spam

2003-06-13 Thread John Kelsey
At 09:19 AM 6/11/03 +0100, [EMAIL PROTECTED] wrote: ... I observe that "confirmation" of the fingerprint by phone is worthless unless the recipient is able to recognise my voice. In the case of a stranger, that won't be the case. It's not quite worthless, as it raises the cost of the attack quite a

RE: Keyservers and Spam

2003-06-13 Thread John Kelsey
At 10:27 AM 6/11/03 -0700, bear wrote: ... That is the theory. In practice, as long as the PGP "web of trust" depends on connections made through signers not personally known to the person depending on the security, it hardly works. There is very little verification done in the web of trust, not

RE: Keyservers and Spam

2003-06-13 Thread Pat Farrell
At 11:56 AM 6/13/2003 -0400, John Kelsey wrote: At 10:27 AM 6/11/03 -0700, bear wrote: That is the theory. In practice, as long as the PGP "web of trust" The thing that strikes me is that the PGP web of trust idea is appropriate for very close-knit communities, where reputations matter and people

Re: Session Fixation Vulnerability in Web Based Apps

2003-06-13 Thread James A. Donald
-- On 12 Jun 2003 at 16:25, Steve Schear wrote: > > > http://www.acros.si/papers/session_fixation.pdf "James A. Donald" > > Wow. > > > > This flaw is massive, and the biggest villain is the server > > side code created for Apache. On 13 Jun 2003 at 11:16, tom st denis wrote: > You really la

RE: Keyservers and Spam

2003-06-13 Thread Bill Frantz
At 2:35 PM -0700 6/13/03, Pat Farrell wrote: >At 11:56 AM 6/13/2003 -0400, John Kelsey wrote: >>At 10:27 AM 6/11/03 -0700, bear wrote: >>>That is the theory. In practice, as long as the PGP "web of trust" >> >>The thing that strikes me is that the PGP web of trust idea is appropriate >>for very cl

RE: Keyservers and Spam

2003-06-13 Thread Anne & Lynn Wheeler
At 11:56 AM 6/13/2003 -0400, John Kelsey wrote: The thing that strikes me is that the PGP web of trust idea is appropriate for very close-knit communities, where reputations matter and people mostly know one another. A key signed by Carl Ellison or Jon Callas actually means something to me, bec

Re: SDSI/SPKI background

2003-06-13 Thread Carl Ellison
At 12:00 PM 6/13/2003 +0200, Stefan Mink wrote: > >Hi Carl, > >On Wed, Jun 11, 2003 at 09:56:12PM -0700, Carl Ellison wrote: >> There's one draft that should have gone on to RFC, but people were >> using it from the draft instead. It's my fault that we left it at >> that stage and didn't publish t

Re: Session Fixation Vulnerability in Web Based Apps

2003-06-13 Thread Rich Salz
> To make the system entirely secure against this attack, we need > to be able to enforce a one to one mapping between login > sessions and https sessions. The existing tools for writing > server side code do not provide us with any direct means of > enforcing such a relationship. I'm not paying