Re: Why are mail servers not also key servers?

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 20 April 2017 15:23 UTC

Return-Path: <ietf-dane@dukhovni.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 4BF7E126E3A for <ietf@ietfa.amsl.com>; Thu, 20 Apr 2017 08:23:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.658
X-Spam-Level:
X-Spam-Status: No, score=-0.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NUMERIC_HTTP_ADDR=1.242] 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 1VXj8qHNEDPX for <ietf@ietfa.amsl.com>; Thu, 20 Apr 2017 08:23:45 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAC73129AAC for <ietf@ietf.org>; Thu, 20 Apr 2017 08:23:43 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 00A0E7A3309; Thu, 20 Apr 2017 15:23:42 +0000 (UTC)
Date: Thu, 20 Apr 2017 15:23:42 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org
Subject: Re: Why are mail servers not also key servers?
Message-ID: <20170420152342.GM25754@mournblade.imrryr.org>
Reply-To: ietf@ietf.org
References: <849511c0-6526-ecbe-2b56-7b459eaf010b@hawaii.edu> <alpine.LRH.2.20.999.1704201016120.518@bofh.nohats.ca> <FC831208-97A3-4F1B-A37C-F8646C3FB208@gmail.com> <alpine.LRH.2.20.999.1704201055590.1457@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <alpine.LRH.2.20.999.1704201055590.1457@bofh.nohats.ca>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/BJ_D_XFBVZcy-fdFtrWjzx2JLyM>
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: Thu, 20 Apr 2017 15:23:47 -0000

On Thu, Apr 20, 2017 at 11:08:20AM -0400, Paul Wouters wrote:

> > I want to send you an email, so I type “paul@nohats.ca” in the To: field, and my MUA goes to
> > https://mail-public-keys.nohats.ca/.well-known/mail-pubkeys/paul and that gets your public key.
> 
> But any MUA can already get my key using RFC-7929 at sha256("paul")[1:28]._openpgpkey.nohats.ca
> 
> eg:
> 
> dig openpgpkey 0357513deb903a056e74a7e475247fc1ffe31d8be4c1d4a31f58dd47._openpgpkey.nohats.ca.
> 
> So using another HTTP(S) server that is not the SMTP server itself does
> not seem to make much sense to me? An SMTP server relaying the
> OPENPGPKEY or SMIMEA or other source of pubkey could be useful,
> if we think DNS transport is bigger problem than ESMTP transport.
> But I think it is harder for people to contact mx.nohats.ca on port
> 25 from a random ISP compared to use DNS against 8.8.8.8 on an ISP
> network.

This was all covered in the discussion of draft-moore-email-addrquery.
(Perhaps on the UTA rather than DANE list? I don't recall)

My take at the time was (and remains) that queries for the recipient's
public key can be tunneled through the user's MSA, thereby avoiding
the issue of inability to reach port 25 from consumer end-device
IP space.  That discussion unfortunately appears to have worn-out
the draft author.  

I still think that draft is worth pursuing, if one is willing to
not set the bar too high.  The reason we have so little security
is sometimes (often?) because we're unwilling to accept less than
"perfect" security.  It is not unreasonable to trust the MSA to be
a trusted proxy for remote keys.  After all, in that model the same
MSA/MTA operator is trusted to vend your keys to others.

-- 
	Viktor.