Re: Why are mail servers not also key servers?

Doug Royer <douglasroyer@gmail.com> Fri, 21 April 2017 15:39 UTC

Return-Path: <douglasroyer@gmail.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 387D012954C for <ietf@ietfa.amsl.com>; Fri, 21 Apr 2017 08:39:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 eBO5KleKYPms for <ietf@ietfa.amsl.com>; Fri, 21 Apr 2017 08:39:27 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53426129535 for <ietf@ietf.org>; Fri, 21 Apr 2017 08:39:27 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id j201so100186944oih.2 for <ietf@ietf.org>; Fri, 21 Apr 2017 08:39:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to; bh=+HXAQ5qRlmRHHPwBxEWmWiiOf75u6CHv+Vb3wW2UKuE=; b=s5Y9E2PNi3FT+RGy3gR7VbjOkxHiYsyqBK8irTEUoZII94uotkm2F1BrxbxuX3d36U 7bJglYfj4WQKOGbCkj2+MTSwfQP+VX47pMH9X0J0CQp0xjz1DyzFeKm+DFak6dQZI7bL /bgjgoPRrLZYzSqPwxxnjBTpimYZ3aF15+lgsT5mUqRCSSFTRqXMOkzYeujH+nTWQOOq kEr1Sr4agMA/JQMGpHBiwDNQvALuWh6SqdsN0yrGM9chZ7iHKAfKJnfsA3AtsefsqdCG 6/ddvSBOK19c5WSuIkeyo00Ofrbwg1wG9RCjI/GOeEhsqhjRRvgZs+IChRfVWMlUpH8v /tFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=+HXAQ5qRlmRHHPwBxEWmWiiOf75u6CHv+Vb3wW2UKuE=; b=tBYhf1joGIc2iV0SOt37CcF9Ejbve/5tCPiQ94Cy38D3Uo+0zLql6MO6z7bk3LEJ68 Oc4QdpaKxM2Xar+IAbB00eJjE4LjGKYktcl9ANOooanzjKAA/utIZ9ha7LJNL0mcE4bm Uk1OYsB6AKVx2DU7cL87n0yErHriEVfpLZfDL5TY70A1SDkaAtNy91z3KVrKBaHDmsqY iXhXSjQKSK6OiEZylZHeI+WklZFGYeBNFAjUUJhyuypc00FX5iSLSgfMy6Sb3PXZeIXd GbYmIEgB3tnLNjJYbZBa7UruZH9rHgTJSwrqFvHEw+CjUpRk6SI68Hgs0vB1fysuM3p3 ldYw==
X-Gm-Message-State: AN3rC/5QVdr/vuMXwrxZTS3Mk5KOlKpQA5g4lHd4aMzlKVuHyvZWsfZu ml+aqrBN2Jlbd0bKFHY=
X-Received: by 10.202.177.131 with SMTP id a125mr7280252oif.2.1492789166239; Fri, 21 Apr 2017 08:39:26 -0700 (PDT)
Received: from ?IPv6:2602:ae:1b37:7300::2? ([2602:ae:1b37:7300::2]) by smtp.googlemail.com with ESMTPSA id 63sm4153874otw.57.2017.04.21.08.39.24 for <ietf@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 08:39:24 -0700 (PDT)
Subject: Re: Why are mail servers not also key servers?
To: ietf@ietf.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> <9440cd43-d8d9-8950-cdc7-bbf9fd2d7a91@gmail.com> <CAMm+LwgboKwXs+uEUCDA=KMbWHgFU6iVOvQZPMOvS0S4Omu8ew@mail.gmail.com>
From: Doug Royer <douglasroyer@gmail.com>
Organization: http://SoftwareAndServices.NET
Message-ID: <3f0ebabd-1eb9-d81b-7cda-47d7ace3f57b@gmail.com>
Date: Fri, 21 Apr 2017 09:39:23 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0
MIME-Version: 1.0
In-Reply-To: <CAMm+LwgboKwXs+uEUCDA=KMbWHgFU6iVOvQZPMOvS0S4Omu8ew@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030301070006030200080107"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ER6nvyxIO_zF5tElr8FU00ZDzAs>
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:39:29 -0000

On 04/21/2017 08:24 AM, Phillip Hallam-Baker wrote:
> ...
> 
> Tweaking the SMTP mail infrastructure doesn't help because the sending 
> and receiving device do not interact with either server directly under 
> the current model. SMTP email has grown to meet a lot of important 
> requirements in ways that make repurposing SMTP mail servers a non starter.
> 

They do not, does not mean they can not. So, maybe SMTP server is not 
the correct place. But MX host might be, with a public key server on a 
different port. Because the MX host is currently the authority for an 
email addresses validity checking (well it bounces it if its not valid - 
but it knows if its valid).

Is it repurposing? Is this really different?

   RCPT TO user@domain
   250 OK
   550 No such user here

   PEMCERT user@domain
   250 OK ...PEM-encoded-cert..
   550 No such user here

   PGPCERT user@domain
   250 OK ...PGP-encoded-cert..
   550 No such user here

Thoughts below on this. And I am thinking of how the code would be 
written ...

I was leaning towards the SMTP/MX server because its currently the only 
place of authority where you can find out if user@host is valid. If you 
send a RCPT TO and it says, NO, then your done.


I have no problem with another solution. I just think you would have to 
replicate the email address validity check problem as part of that other 
implementation. 'User' is not always the same as email address. So any 
new service would have to know about email proxy rewrite rules 
(Doug.Royer@gateway -> dougr@his-site-server),  mailing/distribution 
lists, ... and the mess goes on.

I am not saying a public key server would need to understand those 
rules. I am saying that Doug.Royer@gateway would be the public key you 
might need. I am saying a public key server would need to parallel the 
knowledge of what the SMTP server already knows is a valid email address 
for its site. Currently Doug.Royer@gateway is in some file/database as 
valid in a way that is currently unique the SMTP server implementation.

And, who is the local authority for the public cert of 
Doug.Royer@gateway? The SMTP server already knows it goes to 
dougr@his-site-server.

So, maybe the SMTP server is not the place. I think it would make for a 
simpler implementation. Or maybe an entirely news service, that the SMTP 
server would use, to make sure they are in sync.

It seems to me that a completely new approach is not going to be adopted 
as quickly as extending SMTP.

Or I could see the SMTP server implementation also opening up a new 
public key service port that is only used for fetching public keys. And 
that port could use a non-SMTP protocol. However the MX host is the 
authority.

Lets not make two authorities.

-- 

Doug Royer - (http://DougRoyer.US  http://goo.gl/yrxJTu )
DouglasRoyer@gmail.com
714-989-6135