IETF Logo Mail Archive

Re: Why are mail servers not also key servers?

Rich Kulawiec <rsk@gsp.org> Fri, 21 April 2017 13:35 UTC

Return-Path: <rsk@gsp.org>
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 A29D81270A3 for <ietf@ietfa.amsl.com>; Fri, 21 Apr 2017 06:35:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 BP2TFBHgAwiQ for <ietf@ietfa.amsl.com>; Fri, 21 Apr 2017 06:35:37 -0700 (PDT)
Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4328C1205F1 for <ietf@ietf.org>; Fri, 21 Apr 2017 06:35:37 -0700 (PDT)
Received: from gsp.org (localhost [127.0.0.1]) by taos.firemountain.net (8.15.1/8.14.9) with SMTP id v3LDZZHW014918 for <ietf@ietf.org>; Fri, 21 Apr 2017 09:35:35 -0400 (EDT)
Date: Fri, 21 Apr 2017 09:35:35 -0400
From: Rich Kulawiec <rsk@gsp.org>
To: ietf@ietf.org
Subject: Re: Why are mail servers not also key servers?
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <32b6bba4-cd4b-167f-b3d1-36733d1504c2@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/wNdBtyWF3Jv6Eg6SIKVPybMY2js>
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 13:35:39 -0000

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.

---rsk

v2.23.0 | Report a Bug | By Email