Re: [dix] Agenda bashing
Eliot Lear <lear@cisco.com> Thu, 06 July 2006 06:12 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyN6O-0004mN-1K; Thu, 06 Jul 2006 02:12:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyN6M-0004mC-E3 for dix@ietf.org; Thu, 06 Jul 2006 02:12:38 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyN6L-0008Hd-5G for dix@ietf.org; Thu, 06 Jul 2006 02:12:38 -0400
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 05 Jul 2006 23:12:37 -0700
X-IronPort-AV: i="4.06,211,1149490800"; d="scan'208"; a="327441121:sNHT31001098"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k666Caif000390; Wed, 5 Jul 2006 23:12:36 -0700
Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k666Ca9s026411; Wed, 5 Jul 2006 23:12:36 -0700 (PDT)
Received: from [212.254.247.3] (ams3-vpn-dhcp4298.cisco.com [10.61.80.201]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k66672Pn028964; Wed, 5 Jul 2006 23:07:02 -0700
Message-ID: <44ACA9CF.7090605@cisco.com>
Date: Thu, 06 Jul 2006 08:12:31 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530)
MIME-Version: 1.0
To: Digital Identity Exchange <dix@ietf.org>
Subject: Re: [dix] Agenda bashing
References: <20060703172550.A182A222425@laser.networkresonance.com> <44A973DC.9040801@cisco.com> <86zmfqa0au.fsf@raman.networkresonance.com> <8C86E9E37E4BD3C-1288-2A5B@FWM-D05.sysops.aol.com>
In-Reply-To: <8C86E9E37E4BD3C-1288-2A5B@FWM-D05.sysops.aol.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Authentication-Results: sj-dkim-3.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; );
DKIM-Signature: a=rsa-sha1; q=dns; l=1433; t=1152166356; x=1153030356; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20<lear@cisco.com> |Subject:Re=3A=20[dix]=20Agenda=20bashing; X=v=3Dcisco.com=3B=20h=3D6inNqoEUmFyA1l2ZAW91r5N7nQI=3D; b=divw/Esyn8UknmeQ7qXy9tcDTnRKOApOhKrukzcKkEm3OKpMLP8EN/oGAsDgDNfh72G3j0HA 1MOnUmpKi7dp50p2CRJa5ByuLa1ZGGmoudIpSAECZdCJObEI3Us2mDu6;
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc:
X-BeenThere: dix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Digital Identity Exchange <dix@ietf.org>
List-Id: Digital Identity Exchange <dix.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dix>, <mailto:dix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dix>
List-Post: <mailto:dix@ietf.org>
List-Help: <mailto:dix-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dix>, <mailto:dix-request@ietf.org?subject=subscribe>
Errors-To: dix-bounces@ietf.org
thayes0993@aol.com wrote: > I believe that PwdHash does rely on a certain level of proof of the > server's identity. The browser needs to decide that > the domain name that the server is presenting actually belongs to it. > This is usually done by relying on SSL/TLS. > If the false server can convince the browser that it is in fact the > targeted domain, then the browser will happily > transmit the full credential (H(password, domain)) to the server. > > PwdHash does NOT require that the proved domain match anything the > user has in mind. That is, the identity > does not need to be presented to the user, or compared against > anything the user is doing. This seems to be the > primary problem in phishing attacks (the last foot). That's where the > real advantage of techniques like PwdHash are. Pretty neat. There are two problems that still really need to be addressed. The first is that you need to manage a transition. It must be clearly visible to the user when PwdHash is used and when it is not. Otherwise someone just phishes the original password and that's the ball game. Second, PwdHash still relies on the underlying security of the user's computer. I don't know about you but that is a goal I would like to address. I want a means to have a secure opaque channel of communication between the server and the smart card. That's what I'm looking for from the IETF. Eliot _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix
- Re: [dix] Agenda bashing Eliot Lear
- [dix] Agenda bashing Pete Resnick
- Re: [dix] Agenda bashing Eliot Lear
- Re: [dix] Agenda bashing Eric Rescorla
- RE: [dix] Agenda bashing Hallam-Baker, Phillip
- Re: [dix] Agenda bashing Eric Rescorla
- Re: [dix] Agenda bashing Pete Resnick
- Re: [dix] Agenda bashing Eric Rescorla
- Re: [dix] Agenda bashing Haripriya S
- Re: [dix] Agenda bashing Eric Rescorla
- Re: [dix] Agenda bashing thayes0993
- Re: [dix] Agenda bashing Eric Rescorla
- Re: [dix] Agenda bashing Eliot Lear
- Re: [dix] Agenda bashing Ben Laurie
- Re: [dix] Agenda bashing Eliot Lear
- Re: [dix] Agenda bashing Eric Rescorla
- RE: [dix] Agenda bashing Hallam-Baker, Phillip
- Re: [dix] Agenda bashing Eric Rescorla
- Re: [dix] Agenda bashing Eliot Lear
- Re: [dix] Agenda bashing Eliot Lear
- Re: [dix] Agenda bashing Eric Rescorla
- Re: [dix] Agenda bashing Eliot Lear
- Re[2]: [dix] Agenda bashing Chris Drake