Re: Why are mail servers not also key servers?
Phillip Hallam-Baker <phill@hallambaker.com> Fri, 21 April 2017 15:29 UTC
Return-Path: <hallam@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 48055129532 for <ietf@ietfa.amsl.com>; Fri, 21 Apr 2017 08:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 FNu1R9dmOVe1 for <ietf@ietfa.amsl.com>; Fri, 21 Apr 2017 08:29:06 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 9BAB1127B60 for <ietf@ietf.org>; Fri, 21 Apr 2017 08:29:06 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id x184so100422884oia.1 for <ietf@ietf.org>; Fri, 21 Apr 2017 08:29:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vCuQIchAjl8+Ei2V3hqEW7Dd/tblaw7vBA1mWBd6SAs=; b=kCd01HBEXmAizAzXISKaaUnRV0+2WndUB/SFsB5QzK2uQkNrRKW9+zmkCkR+9oKZoy Wn0wnbK/dtzwzB+CHjRoBNu9InsBdzUjRP5WCMV90Nm8LHyn4Wbn02J8HAO0wd02hIPX 25CznFWlHHk/2VFpXoQIlK2wZ+xtUEnOf1m7K8mkVFJcdznAI/Vf+OTaQ51vT9zA47LS 3HUmA6nSd9fQe5VS6J39DOqlYLTf8gQvm3BReelpySewydIDZhevyeXMEx9aGX8p2wGF uXvf6Wg+37Pe8tLiBFzBRz7c7dZmQZtEYdSopJ9f1ZQq7VB5Bi+0FbDc6ZktY9HYKv1B bkdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vCuQIchAjl8+Ei2V3hqEW7Dd/tblaw7vBA1mWBd6SAs=; b=mdMaL4NA0q6Er0aAClEGCKmiFhAGp0q4ClwopQqd+eXFkjkY8cqK2yfINQVhKoS4jC zVAtbVskMAo9BU/BLk4Zb7EGMjDgldqtDgaXaeC3kCm3chuWPL0495CvOM5OLYNcNTcK roVuzKrdEGkXR9hhozcl8tjkokwqphGeW6ocdjo0CScEuXa5HgViLNQ5mYaFf86SXAXQ /ajuVE2eTbYAIN2YXSfgqEnndxog440yzTgT/9TX3V9l/SuAimeYqN2ktMXy6FZDFxcF 9/jSJ5EILE/8Z/oLyCUDdz7smiyHa0Cd4IaP/n+821fMrdOf5jkUx+u49o1J4o3AytF0 LY4g==
X-Gm-Message-State: AN3rC/50GUjHRfKaU8L64ibJ0vktJTxbHkIi3FJo2fYGLHZhMA/6lVEd d545pa7VRDgUSWUTX4kOGIJSPF6/Zw==
X-Received: by 10.157.46.9 with SMTP id q9mr4832425otb.102.1492788545895; Fri, 21 Apr 2017 08:29:05 -0700 (PDT)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.157.22.175 with HTTP; Fri, 21 Apr 2017 08:29:05 -0700 (PDT)
In-Reply-To: <m1d1ZpH-0000HJC@stereo.hq.phicoh.net>
References: <c4492e1e-aa10-b163-6525-7420ef5e4ffd@gmail.com> <m1d1ZpH-0000HJC@stereo.hq.phicoh.net>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 21 Apr 2017 11:29:05 -0400
X-Google-Sender-Auth: R73e_mYljnt2NyKA5-j9eOoH9k4
Message-ID: <CAMm+LwjMt07p_Oz3KxvE5EY=ydsFZ1HCOj9ZK15vo=x4vPfYfg@mail.gmail.com>
Subject: Re: Why are mail servers not also key servers?
To: Philip Homburg <pch-ietf-6@u-1.phicoh.com>
Cc: IETF Discussion Mailing List <ietf@ietf.org>, Doug Royer <douglasroyer@gmail.com>
Content-Type: multipart/alternative; boundary="001a114639dc00c09c054daeeba9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ktl2xEej2pQrQTYqYTbeVs5jc3k>
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:29:09 -0000
On the trust issue, one of the problems I have identified with existing message level security schemes is the lack of an infrastructure to adequately manage user private keys. This is in part a result of the constraints of 1990s technology which took seconds to perform RSA operations. Today, those constraints are no longer relevant. If we are going to have a useful discussion about Trust, we have to talk metrics. Otherwise we end up with handwavy arguments like'nobody can trust a CA'. Oh really, you think that email about Johnny making the school choir that you currently send en-clair can't be trusted to CA issued trust? When I worked on the design of what is now the WebPKI in the early 1990s at CERN, I used a Work Factor analysis that is denominated in dollars. In the wake of BlockChain, I realized that the model had to be extended to take account of time because the wonderful thing about BlockChain and any Lamport hash chain is that the Work Factor of an attack goes to essentially infinity as soon as a data item is enrolled. https://datatracker.ietf.org/doc/draft-hallambaker-prismproof-trust/ The big problem with private keys is that people have multiple devices and they HAVE to be able to read email on more than one. Which means that either you have to re-engineer the mail crypto to use proxy re-encryption or you have to be able to move private keys about. I am currently completing the code for the second approach. My scheme in a nutshell is to establish a personal PKI for each user and give them the tools to manage it transparently. OpenPGP offers something similar but it isn't designed to allow a user to keep a personal fingerprint for their whole life. Mine is and making that possible requires the same offline/intermediate/online approach we use to manage WebPKI keys. Each key in my scheme has a very narrow purpose. That means more public key operations but greatly simplifies the code. So let us say that the fingerprint for Alice's personal Mesh is MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ. We can use this to create a strong DNS address so: example.com.mm--MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ which allows us to construct a strong email address: alice@example.com.mm--MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ mm-- is a DNS label prefix following the practice established for 118N domains. It is the top level because it is the root of this particular naming scheme and we do not want anyone to be able to resolve this name unless they understand the mm-- prefix. Try to send a mail with that address using a regular email client and it will fail. Which is exactly what I want. This allows me to support the use case 'only send if it can be encrypted'. In this case, the fingerprint is of a personal signing key which signs Alice's Mesh profile which in turn signs Alice's Mail profile which describes how to send email to Alice. So if a mail is sent to that address, following the specified profile, it has been sent securely (for Alice's definition of secure). There is no opportunity for a third party to compromise the communication. You are not relying on any CA or TTP for trust. What you probably will end up doing if you are an Enterprise customer is paying some party some money to run the infrastructure that maps MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ to the necessary resources and also helps you address the first contact and promiscuous encryption use cases. There is a business model for existing CAs here but the services are rather more than signing a certificate. The concept of strong addresses can be applied to any IETF protocol and is wonderfully back compatible because every strong DNS address is a valid DNS address but one that has no chance of accidentally being confused with an ICANN issued address. It would take an act of intentional malice for confusion to arise. So how to apply these to the use case raised by John Levine? We could configure a mail client to add a header that includes strong email address as a header: From: alice@example.com Strong-Address: alice@example.com.mm--MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ This gives us Trust After First Use (TAFU) which is a great way to build a Web of Trust. It does work for SSH. It is fine for interpersonal messages. If you combine Web of Trust and Trusted Third Party models, you can achieve a higher work factor than is possible with either alone.
- Why are mail servers not also key servers? Jon
- Re: Why are mail servers not also key servers? Nico Williams
- Re: Why are mail servers not also key servers? Viktor Dukhovni
- Re: Why are mail servers not also key servers? Paul Wouters
- Re: Why are mail servers not also key servers? Yoav Nir
- Re: Why are mail servers not also key servers? Yoav Nir
- Re: Why are mail servers not also key servers? Paul Wouters
- Re: Why are mail servers not also key servers? Viktor Dukhovni
- Re: Why are mail servers not also key servers? Matthew Kerwin
- Re: Why are mail servers not also key servers? Jon
- Re: Why are mail servers not also key servers? Nico Williams
- Re: Why are mail servers not also key servers? Doug Royer
- Re: Why are mail servers not also key servers? Viktor Dukhovni
- Re: Why are mail servers not also key servers? Doug Royer
- Re: Why are mail servers not also key servers? Doug Royer
- Re: Why are mail servers not also key servers? John Levine
- Re: Why are mail servers not also key servers? Paul Wouters
- Re: Why are mail servers not also key servers? Phillip Hallam-Baker
- RE: Why are mail servers not also key servers? Paul Wouters
- RE: Why are mail servers not also key servers? Rui Costa
- RE: Why are mail servers not also key servers? Rui Costa
- Re: Why are mail servers not also key servers? Martin Thomson
- Re: Why are mail servers not also key servers? Doug Royer
- Re: Why are mail servers not also key servers? Doug Royer
- Re: Why are mail servers not also key servers? John Levine
- Re: Why are mail servers not also key servers? Philip Homburg
- Re: Why are mail servers not also key servers? John Levine
- Re: Why are mail servers not also key servers? Phillip Hallam-Baker
- Re: Why are mail servers not also key servers? Doug Royer
- Re: Why are mail servers not also key servers? Doug Royer
- Re: Why are mail servers not also key servers? Rich Kulawiec
- Re: Why are mail servers not also key servers? John C Klensin
- Re: Why are mail servers not also key servers? Doug Royer
- Re: Why are mail servers not also key servers? John C Klensin
- Re: Why are mail servers not also key servers? Doug Royer
- Re: Why are mail servers not also key servers? Phillip Hallam-Baker
- Re: Why are mail servers not also key servers? Philip Homburg
- Re: Why are mail servers not also key servers? Doug Royer
- Re: Why are mail servers not also key servers? Phillip Hallam-Baker
- Re: Why are mail servers not also key servers? Wei Chuang
- Re: Why are mail servers not also key servers? Phillip Hallam-Baker
- Re: Why are mail servers not also key servers? John R Levine
- Re: Why are mail servers not also key servers? Martin Thomson
- Re: Why are mail servers not also key servers? Phillip Hallam-Baker
- Re: Why are mail servers not also key servers? Dave Crocker
- Re: Why are mail servers not also key servers? Doug Royer
- Re: Why are mail servers not also key servers? Doug Royer