Re: [ietf-smtp] Public Key Look Up

John C Klensin <john-ietf@jck.com> Wed, 12 May 2021 03:48 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 4D5213A3213 for <ietf-smtp@ietfa.amsl.com>; Tue, 11 May 2021 20:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OCyTuCa5JIOR for <ietf-smtp@ietfa.amsl.com>; Tue, 11 May 2021 20:48:00 -0700 (PDT)
Received: from bsa2.jck.com (ns.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 779733A3212 for <ietf-smtp@ietf.org>; Tue, 11 May 2021 20:48:00 -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 1lgfqo-000DV9-HS; Tue, 11 May 2021 23:47:58 -0400
Date: Tue, 11 May 2021 23:47:52 -0400
From: John C Klensin <john-ietf@jck.com>
To: John Levine <johnl@taugh.com>, ietf-smtp@ietf.org
cc: vesely@tana.it
Message-ID: <D7EABCF7E8976BE735927C69@PSB>
In-Reply-To: <20210511185543.C751179052B@ary.qy>
References: <20210511185543.C751179052B@ary.qy>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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/zffGC1ypgwoTJrpBIDZsz2nZu1k>
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 03:48:06 -0000


--On Tuesday, May 11, 2021 14:55 -0400 John Levine
<johnl@taugh.com> wrote:

> It appears that Alessandro Vesely  <vesely@tana.it> said:
>>> I think it's a terrible idea both because it puts the keys
>>> in the wrong place and the reasons you gave, extensions are
>>> optional which means not implemented.
>> 
>> I'm not clear why a domain's MX would be the wrong place.
> 
> Because you can't tell the user's relation to the domain.
> Would you want Google to be the authoritative source of keys
> for every gmail user?  Apollo Global Management for every
> Yahoo and AOL user?

Well, if the keys were signed by entities I trusted, I wouldn't
be worried about what "authoritative source" means.  And if they
weren't, not only would I not like that, but it would probably
turn the whole idea into theater rather than security.   And, as
you know at least as well as I do, getting general-purpose keys
signed in a way that could be generally depended on has proven
to be a challenge.(to put it mildly).

And you didn't ask the question of why Google would want to go
into that business given that it would increase their
liabilities, not add significantly to what they already know
about gmail users or the ability to sell ads, and increase the
costs of a "free" service.  But perhaps I'm missing something.

> Personally, as a passive-aggressive mail system operator, the
> only keys my MX would publish would be proxy ones that let my
> MTA decode the mail and do spam and malware filtering.  If my
> users don't like that, they can manage their own fripping keys.

Yeah, something like that.
best,
   john