Re: [ietf-smtp] Public Key Look Up
John C Klensin <john-ietf@jck.com> Sat, 08 May 2021 16:27 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880513A1E93; Sat, 8 May 2021 09:27:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 E3tsaVopNRkI; Sat, 8 May 2021 09:27:31 -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 651023A1E8F; Sat, 8 May 2021 09:27:28 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1lfPnZ-000OUp-IZ; Sat, 08 May 2021 12:27:25 -0400
Date: Sat, 08 May 2021 12:27:19 -0400
From: John C Klensin <john-ietf@jck.com>
To: Jeremy Harris <jgh@wizmail.org>, ietf-smtp@ietf.org, patrick.peisker=40protonmail.com@dmarc.ietf.org
Message-ID: <2A1D13B4D5EFA6CA70790D60@PSB>
In-Reply-To: <dbfa2ca5-1182-43c9-4964-2ae1484c881e@wizmail.org>
References: <A7ef6qMfEC_041hZ5eKyUp-5y7ntO2P6uXlp29O6z8Ygt5LH79ziGPhRl0GqcVR24ZegVbPyJngGL1z5OnqRvZysnFJhmLZV7nfbdOsp1Y4=@protonmail.com> <dbfa2ca5-1182-43c9-4964-2ae1484c881e@wizmail.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.10
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-smtp/bj0XZtyglmv7uQ83s6OTHd75C3w>
Subject: Re: [ietf-smtp] Public Key Look Up
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 May 2021 16:27:37 -0000
--On Saturday, May 8, 2021 15:43 +0100 Jeremy Harris <jgh@wizmail.org> wrote: > On 08/05/2021 15:03, > patrick.peisker=40protonmail.com@dmarc.ietf.org wrote: >> In order to address this interoperability issue in a >> standards centric approach, the proposal is the addition of a >> new SMTP command to allow the retrieval of a recipients >> public key prior to the transmission of a mail. This will >> enable the sender to encrypt the email content before the >> same is transmitted through the existing SMTP commands. > > This requires the MUA to be a full MTA not just an MSA passing > off outbound traffic to a real MTA, Not the current usual > architecture. > > It also doesn't work with traditional-forwarding, I think, > unless the forwarder decrypts and re-encrypts. Noting that things very similar to this have been proposed before, it also does not work with relays. The problem as really the same as with VRFY: (which could, in principle, easily be extended to do this). First, one need to be able to ask the final recipient system whether an email address is valid and deliverable and then get the key for it. But much of the community has already decided that the validity check itself is a security and/or privacy violation and a bad idea, so VRFY is not nearly as broadly supported as it was 20 or 30 years ago. Now, one could imagine a different way to do this. One could imagine a different kind of mail transaction and command associated with GETK. Unlike VRFY, which needs to expect a reply equivalent to "don't have a clue" if the comment reaches a relay that does not have an accurate list and profile of valid addresses at the destination and willingness to give them out (as well as the MUA problem Jeremy mentions) GETK would act more like SOML: if it reaches a system that has the data, it provides it and, if it doesn't, it relays to the next system in the MX page. That, of course, means that one would need to invent a new type of message disposition format, might need to worry about blowback prevention or the like, would need to discuss whether one could issue GTKY commands during conventional mail transaction (in which MAIL commands are also present), how many of them could be issued in a session, etc.: lots of details to be sorted out. And I'd predict that getting MSAs and MTA (including both relay and delivery configurations) to implement it and convincing people to configure it would be a hard sell. But it is probably possible. FWIW, also note that ideas of putting user or mailbox names (not just host names) into the DNS to support a variety of things has been around since the early design of the DNS.. and that proposals to do that to allow public key retrieval have been around almost since there have been public keys. Not much traction there either --even though it would be lots less complex than trying to extend SMTP to do it through relays-- and probably for good reason. I want to stress that I don't think this is a terrible idea, especially if it were used to retrieve keys for S/MIME or PGP use rather than inventing yet another mechanism. I do see it as rather difficult to get implemented and widely enough deployed to be useful (see John Levine's note, which arrived after this message was nearly finished and to which I will respond soon). I would, however, think about looking at this a different way. At least for PGP, there are widely available public key stores from which an interested MUA could easily retrieve any keys that happen to be there using LDAP and probably other mechanisms -- all less complicated than building something into SMTP. The main problem with those systems has been getting people to put keys in there, especially keys that, instead of being self-signed, are sufficiently more part of some web of trust that one would want to use them. That is slightly less of an issue for encryption than it is for signatures but one needs to be careful about what one believes -- and than opens up the entire can of works with PKI arrangements. Another problem is that many of us use many more email addresses than we use keys, some with so-called subaddresses arrangements and, to the best of my knowledge, no one has sorted out the right arrangements for LDAP, arrangements that don't rather seriously break SMTP principles. If I remember, this message will be signed, but the key does not have "john-ietf@jck.com as one of the addresses on it. In some cases, that might be an advantage for a proposal like the one you suggest -- in my case, the final delivery server knows, or could easily know, how to short such things out but, to use John's example, Google and Comcast probably don't. In particular, you (Patrick) wrote: > As the SMTP standard is widely adopted, the introduction of > such a command could exponentially increase the adoption of > more secure email communication. Alternative options such as > the use of separate and dedicated key stores to solve this > issue have not only be unsuccessful to drive higher security > for email communication, but they also operate outside of the > established standards and infrastructure deployed by email > providers across the globe. What I think you are missing is that SMTP implementations are not required to implement any given extension. Even if the IETF decided to work out the details of "GETK" and require it, that requirement would not mean much. So I don't think you can extrapolate from SMTP is widely deployed" to "this would be". I fear that, until there are major changes in attitudes and user educations, it would be likely to go the way of those "alternate solutions". best, john
- Re: [ietf-smtp] Public Key Look Up Jeremy Harris
- [ietf-smtp] Public Key Look Up patrick.peisker
- Re: [ietf-smtp] Public Key Look Up John Levine
- Re: [ietf-smtp] Public Key Look Up John C Klensin
- Re: [ietf-smtp] Public Key Look Up John C Klensin
- Re: [ietf-smtp] Public Key Look Up John Levine
- Re: [ietf-smtp] Public Key Look Up Dave Crocker
- Re: [ietf-smtp] Public Key Look Up Alessandro Vesely
- Re: [ietf-smtp] Public Key Look Up John Levine
- Re: [ietf-smtp] Public Key Look Up John C Klensin
- Re: [ietf-smtp] Public Key Look Up Alessandro Vesely
- Re: [ietf-smtp] Public Key Look Up Dave Crocker
- Re: [ietf-smtp] Public Key Look Up John R Levine
- Re: [ietf-smtp] Public Key Look Up Valdis Kl ē tnieks
- Re: [ietf-smtp] Public Key Look Up Alessandro Vesely
- Re: [ietf-smtp] Public Key Look Up Alessandro Vesely
- Re: [ietf-smtp] Public Key Look Up John C Klensin
- Re: [ietf-smtp] Public Key Look Up John C Klensin
- Re: [ietf-smtp] Public Key Look Up Dave Crocker
- Re: [ietf-smtp] Public Key Look Up Dave Crocker
- Re: [ietf-smtp] Public Key Look Up Ned Freed
- Re: [ietf-smtp] Public Key Look Up John C Klensin
- Re: [ietf-smtp] Public Key Look Up Alessandro Vesely
- Re: [ietf-smtp] Public Key Look Up Alessandro Vesely
- Re: [ietf-smtp] Public Key Look Up Richard Clayton
- Re: [ietf-smtp] Public Key Look Up Matthias Leisi
- Re: [ietf-smtp] Public Key Look Up John C Klensin
- Re: [ietf-smtp] Public Key Look Up John R Levine
- Re: [ietf-smtp] Public Key Look Up John Levine
- Re: [ietf-smtp] Public Key Look Up Gene Hightower
- Re: [ietf-smtp] Public Key Look Up Gene Hightower
- Re: [ietf-smtp] Public Key Look Up John Levine
- Re: [ietf-smtp] Public Key Look Up Gene Hightower
- Re: [ietf-smtp] Public Key Look Up John C Klensin
- Re: [ietf-smtp] Public Key Look Up Matthias Leisi
- Re: [ietf-smtp] Public Key Look Up John Levine
- Re: [ietf-smtp] Public Key Look Up patrick.peisker