(no subject)

"Hallam-Baker, Phillip" <pbaker@verisign.com> Fri, 26 August 2005 16:05 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8ghT-0000y9-EB; Fri, 26 Aug 2005 12:05:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8ghN-0000vo-3m for ietf@megatron.ietf.org; Fri, 26 Aug 2005 12:05:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28900 for <ietf@ietf.org>; Fri, 26 Aug 2005 12:04:54 -0400 (EDT)
Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8gi7-0003ST-Mo for ietf@ietf.org; Fri, 26 Aug 2005 12:05:44 -0400
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.1/8.13.1) with ESMTP id j7QG4kn3004263; Fri, 26 Aug 2005 09:04:46 -0700
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Aug 2005 09:04:46 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 26 Aug 2005 09:04:46 -0700
Message-ID: <198A730C2044DE4A96749D13E167AD375A2AB6@MOU1WNEXMB04.vcorp.ad.vrsn.com>
Thread-Index: AcWqV+D48RgQOhQGR6+/OaM19iYtZQ==
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: Keith Moore <moore@cs.utk.edu>
X-OriginalArrivalTime: 26 Aug 2005 16:04:46.0622 (UTC) FILETIME=[E126CBE0:01C5AA57]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org, t.schorpp@gmx.de
Subject: (no subject)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> From: Keith Moore [mailto:moore@cs.utk.edu] 

> > I agree that getting authentication into the email 
> protocols is a good 
> > thing, but TLS does not achieve much more than 
> SPF/Sender-ID in that 
> > respect. DKIM is a much better platform.
> 
> Not clear.  As currently envisioned, DKIM doesn't address phishing 
> because it basically says "I saw this message" rather than "I 
> wrote this 
> message".  

I don't see a problem with that, XML signature does not have any
signature semantics at all.

Signature semantics are a function of the PKI, not the application. The
DNS based key distribution scheme is intrinsically limited to a fairly
weak set of semantics. All you can really know is that a party with a
particular DNS address signed the message.

SSP allow for some semantics such as this domain always signs outgoing
mail

If you want strong semantics you are going to need a much fuller PKI. 

I don't see the lack of a full PKI in DKIM as a problem, we already have
a PKI that is more than sufficient for this purpose, PKIX. All we need
is to define the linkage from DKIM to PKIX and we have a mechanism for
supporting TTP authentication of any credential we might need.

I believe that the credential that is going to be most important is the
brand of the bank, that is what Secure Internet Letterhead is about.

> It doesn't authenticate transmission either because it 
> doesn't record to whom the message was transmitted.  So it 
> addresses the 
> spam problem only if you're willing to take a rather large 
> leap of faith 
> in reputation services that have no reliable basis with which to 
> determine a domain's reputation, and a few other leaps of 
> faith besides.

I see the big problem with blacklists as being their total refusal to
accept accountability to email senders. Their attitude was basically, we
decide how you are going to send email, kapisch? That is really what
'Collateral Damage' was about. Well folk didn't kapisch, and they sued
MAPS into submission pretty quickly. After which the system went from
bad to worse as the blacklists tried to compete by using more and more
coercive means.

Its all about accountability.

We have an existing infrastructure that was designed to issue PKIX
certificates to SSL merchants who the CA had established could be held
accountable. It is not actually the identity that is really important,
it is the ability to hold parties accountable if they default.

> I think DKIM is fixable, but if it stays in its current form it will 
> only delay adoption of effective anti-phishing and anti-spam 
> solutions 
> by a few more years.  And several people in that proto-WG 
> seem to think 
> that getting agreement on something that people have blind 
> faith in is 
> more important than actually understanding whether and how it 
> will solve 
> any real problems.

I think that the problem is the common one of thinking that the way to
get a group to act quickly is to specify the smallest possible charter,
even if this means that the job is only half finished.

I think it would be much better to accept that email authentication is
going to be a longer job.

Instead of proposing a twelve month charter with minimal deliverables I
think that the group should have a longer charter, two or three years
would be more realistic.

The existing milestones could be left in place. Any TTP infrastructure,
whether reputation based or accreditation based is going to need a solid
authentication core to build upon. 


What I don't think is acceptable is a group saying that they are not
going to address a part of a problem because 'we do not understand it'
to quote Dave Crocker's much repeated assertion. There is a wealth of
expertise in that particular field and one of the Security ADs is
generally considered to be one of the leading experts. The point of
working in an environment like the IETF is precisely the fact that email
experts can share ideas with PKI experts.

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