Re: Why are mail servers not also key servers?

Nico Williams <nico@cryptonector.com> Thu, 20 April 2017 16:19 UTC

Return-Path: <nico@cryptonector.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 DADF61294E1 for <ietf@ietfa.amsl.com>; Thu, 20 Apr 2017 09:19:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.8
X-Spam-Level:
X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
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 wHtKxDp9ZNmJ for <ietf@ietfa.amsl.com>; Thu, 20 Apr 2017 09:19:09 -0700 (PDT)
Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A88B5128D3E for <ietf@ietf.org>; Thu, 20 Apr 2017 09:19:09 -0700 (PDT)
Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 0F80C30002B26; Thu, 20 Apr 2017 09:19:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=LAM8q5c4wRF/0AIuQiApQvlOVkc =; b=j+F+4JY4wx4l17bbA0VjuQMu75kdM5YkDtcELZpXzxQa44rQSRlsI35EV9R 3yiT4sBhx6D5vnT/utjyEPht5+9JV/NLWT1EdFpPAoQwGLnbJn/WCgyUUsW8KdA4 VrqF+cgw2eejM13Xgq0QQrW6pNozuxWMuvEyMEo91OmxcA+k=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id B480B30002B25; Thu, 20 Apr 2017 09:19:08 -0700 (PDT)
Date: Thu, 20 Apr 2017 11:19:05 -0500
From: Nico Williams <nico@cryptonector.com>
To: ietf@ietf.org
Subject: Re: Why are mail servers not also key servers?
Message-ID: <20170420161904.GE2856@localhost>
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> <20170420152342.GM25754@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20170420152342.GM25754@mournblade.imrryr.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Ab1VnijtUapqr9YeSyf24uImt2A>
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 16:19:11 -0000

On Thu, Apr 20, 2017 at 03:23:42PM +0000, Viktor Dukhovni wrote:
> 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.

+1

The link to DNSSEC could be this:

 - the client should learn via DNSSEC that the user's MSA supports this
   feature, 

and

 - the user's MSA should learn via DNSSEC that the target domain (and
   any MTAs on the way there) supports this feature.

Nico
--