Re: [ietf-smtp] Public Key Look Up

John C Klensin <john-ietf@jck.com> Thu, 13 May 2021 01:46 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 CD5A33A1318 for <ietf-smtp@ietfa.amsl.com>; Wed, 12 May 2021 18:46:08 -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 5q0bZNF7DYoX for <ietf-smtp@ietfa.amsl.com>; Wed, 12 May 2021 18:46:04 -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 6E3963A1311 for <ietf-smtp@ietf.org>; Wed, 12 May 2021 18:46:04 -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 1lh0QI-000IQE-52; Wed, 12 May 2021 21:45:58 -0400
Date: Wed, 12 May 2021 21:45:52 -0400
From: John C Klensin <john-ietf@jck.com>
To: Ned Freed <ned.freed@mrochek.com>
cc: Alessandro Vesely <vesely@tana.it>, John R Levine <johnl@taugh.com>, ietf-smtp@ietf.org
Message-ID: <DDA44A209F46727598F66BB9@PSB>
In-Reply-To: <01RYYGAIK5W20085YQ@mauve.mrochek.com>
References: <20210511185543.C751179052B@ary.qy> <D7EABCF7E8976BE735927C69@PSB> <65ed77dd-78fb-3f1a-7c21-63977620a510@taugh.com> <85e92b39-4dac-a26e-e85f-8edd1a383b83@tana.it> <0BA91F445C48DED0E4BB0C99@PSB> <01RYYGAIK5W20085YQ@mauve.mrochek.com>
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/6grG7wjlkvWY5reFpCjnBX4fR08>
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: Thu, 13 May 2021 01:46:09 -0000


--On Wednesday, May 12, 2021 17:45 -0700 Ned Freed
<ned.freed@mrochek.com> wrote:

> Responding late to this thread... I wanted to note that
> the need to store and manage lots of keys can be addressed
> through the use of identity based encryption, which in effect
> reduces the number of keys you need to store from one per
> user to 1.
> 
> RFCs 5091 and 6508 cover specific IBE schemes, however, for
> introductory material you'll need to look elsewhere.

Good point, at least in theory (see below).  That would also
eliminate the need for per-user entries if using the DNS.

> I also note that there can still be advantages to having
> a per-user lookup (either in or out of band) for the user's
> public key - a lookup has the potential to tell you that
> a given user is actually capable of receiving encrypted
> mail. 

Indeed.

> All that said, making server side implementation easier
> does nothing to solve the real problem: All available
> evidence says that there won't be sufficient uptake to
> matter.

And that is the practice that goes with the theory.  We really
don't have a shortage of mechanisms for locating and retrieving
keys. Unless something changes the conditions that have
frustrated deployment and use, there is no evidence that adding
another mechanism would make enough difference to be worth the
effort (and, as John Levine pointed out, statistically probably
no difference at all).   I can imagine scenarios that would
change the situation, but I don't expect any of them soon and
none of them would cause the presence or absence of one more key
location and retrieval mechanism to be an impediment.

    john