Re: Why are mail servers not also key servers?

John C Klensin <john-ietf@jck.com> Fri, 21 April 2017 15:48 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719A612953F for <ietf@ietfa.amsl.com>; Fri, 21 Apr 2017 08:48:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 L4URMOA1ARxi for <ietf@ietfa.amsl.com>; Fri, 21 Apr 2017 08:48:20 -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 B5B3D129528 for <ietf@ietf.org>; Fri, 21 Apr 2017 08:48:20 -0700 (PDT)
Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1d1anD-000LUj-NC; Fri, 21 Apr 2017 11:48:19 -0400
Date: Fri, 21 Apr 2017 11:48:10 -0400
From: John C Klensin <john-ietf@jck.com>
To: Rich Kulawiec <rsk@gsp.org>, ietf@ietf.org
Subject: Re: Why are mail servers not also key servers?
Message-ID: <E690BED1BD448540F502C8DD@PSB>
In-Reply-To: <20170421133535.GA21229@gsp.org>
References: <849511c0-6526-ecbe-2b56-7b459eaf010b@hawaii.edu> <B897A3A3-4A47-4C74-B79F-4F93C86A338C@gmail.com> <82ab9e4d-05ba-bc39-c7d1-bda6ee8d9be5@hawaii.edu> <32b6bba4-cd4b-167f-b3d1-36733d1504c2@gmail.com> <20170421133535.GA21229@gsp.org>
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.70
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/YelkpXiUHR2XrpAWhgq50cx5yWo>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Apr 2017 15:48:22 -0000


--On Friday, April 21, 2017 09:35 -0400 Rich Kulawiec
<rsk@gsp.org> wrote:

> On Thu, Apr 20, 2017 at 11:48:04AM -0600, Doug Royer wrote:
>> I would like to see an extension so that the MUA could
>> contact the destination server (perhaps their MX record host)
>> and get a users PUBLIC key. Perhaps (just an idea - no
>> screaming please) a new TXT record type that points to the
>> domains PubKey server.
> 
> How's this going to work when the MUA is:
> 
> 	- running on a host that's not connected to the 'net
> 	- running on a host that can't connect to MX's (because
> 		of local firewall rules)
> 	- running on a host that can't connect to MX's (because
> 		they're unreachable or down)
> 	- running on a host that can't connect to MX's (because
> 		they no longer exist)
> 	- running on a host that can connect to the MX's but can't
> 		get the user's public key because the user is no
> 		longer valid
> 	- and so on
> 
> There are way too many failure modes here that will render
> messages that have already been received either temporarily or
> permanently unreadable.

An idea was kicked around some years ago (can't remember if
there was ever an I-D) to create an SMTP extensions that would
work more or less like VRFY to return either the public key of
the server, that of a user associated with an address, or both.
IIR it never got any traction, partially because of the issues
Rich identified about and partially because of the issues others
have mentioned about being sure one reaches the right server
and/or can trust the keys received.

In addition, as others have pointed out, if you can't trust your
email (server) provider, then expecting others to trust keys on
the basis that they are obtained from that server may not make a
lot of sense.

   john