Re: [ietf-smtp] Public Key Look Up

John C Klensin <john-ietf@jck.com> Wed, 12 May 2021 18:13 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7A73A0962 for <ietf-smtp@ietfa.amsl.com>; Wed, 12 May 2021 11:13:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4KmE76JhXdW for <ietf-smtp@ietfa.amsl.com>; Wed, 12 May 2021 11:13:28 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4532F3A095E for <ietf-smtp@ietf.org>; Wed, 12 May 2021 11:13:28 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1lgtML-000GzT-5F; Wed, 12 May 2021 14:13:25 -0400
Date: Wed, 12 May 2021 14:13:19 -0400
From: John C Klensin <john-ietf@jck.com>
To: Alessandro Vesely <vesely@tana.it>, John R Levine <johnl@taugh.com>, ietf-smtp@ietf.org
Message-ID: <0BA91F445C48DED0E4BB0C99@PSB>
In-Reply-To: <85e92b39-4dac-a26e-e85f-8edd1a383b83@tana.it>
References: <20210511185543.C751179052B@ary.qy> <D7EABCF7E8976BE735927C69@PSB> <65ed77dd-78fb-3f1a-7c21-63977620a510@taugh.com> <85e92b39-4dac-a26e-e85f-8edd1a383b83@tana.it>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/BZ7TJ8ghFI4ezBsvIdDBS6ehWHE>
Subject: Re: [ietf-smtp] Public Key Look Up
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2021 18:13:33 -0000


--On Wednesday, May 12, 2021 19:04 +0200 Alessandro Vesely
<vesely@tana.it> wrote:

>... 
>> Indeed.  But if the keys include signatures, it doesn't
>> matter where they come  from, so we're back to asking why
>> nobody seems to use the key servers that  already exist.
> 
> Some people has been using those key servers.  However,
> they're vulnerable to pgp-poisoning attacks[*].
>...
> [*] https://github.com/skeeto/pgp-poisoner

We are getting fairly far off-topic, but ...

There is an extremely straightforward way to resist such
attacks, which is to accept key updates only from the
authenticated key owner or, _maybe_ from one of the existing
signatories whose key is already in the repository.  There are
issues there too, but most of them come down to something John
Levine pointed out earlier in the thread (and that has been
known since the 1990s), which is that PGP's web of trust concept
does not scale very well.  I can think of another defense too,
but, again, we are getting fairly far off-topic.

But, Ale, it seems to me that almost everyone but you is saying
things that ultimately lead to the same place: either that it
would not be a good idea to try to build this into SMTP or that,
we we did, it either wouldn't work or there would not be enough
uptake and deployment to make it useful.  That does not
necessarily mean that we are right and you are wrong, but it
does suggest that this thread is nearing the end of its useful
life.

best,
    john