Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 01 February 2017 21:02 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 A857B1299E8 for <ietf@ietfa.amsl.com>; Wed, 1 Feb 2017 13:02:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 jGS7GryIQZQM for <ietf@ietfa.amsl.com>; Wed, 1 Feb 2017 13:01:57 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5615E1299D8 for <ietf@ietf.org>; Wed, 1 Feb 2017 13:01:57 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 591C8284E4D; Wed, 1 Feb 2017 21:01:56 +0000 (UTC)
Date: Wed, 1 Feb 2017 21:01:56 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
Message-ID: <20170201210155.GI28349@mournblade.imrryr.org>
References: <B9F32633ED13374379C6E0D1@PSB> <20170124193109.68919.qmail@ary.lan>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0F1p//8PRICkK4MW"
Content-Disposition: inline
In-Reply-To: <20170124193109.68919.qmail@ary.lan>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/4w85nya46byluRA9vlvwMgCchfw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: ietf@ietf.org
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: Wed, 01 Feb 2017 21:02:01 -0000

On Tue, Jan 24, 2017 at 07:31:09PM -0000, John Levine wrote:

> >My impression is that there is little problem with the intended
> >underlying spec, but the document text needs some tuning.
> 
> Agreed.  The subsequent section on comparing names would likely
> benefit from clearer instructions, e.g.
> 
> a) if the domain contains A-labels, turn them into U-labels
> b) if the domain still contains R-LDH labels, stop, not a valid name.
> c) if the domain contains NR-LDH labels, make them all the same case
> d) do a straight byte comparison of the addresses

I think that restricting R-LDH labels that are not A-labels is too
strict, see for example Phil Hallam-Baker's proposed encapsulation
of email addresses with "the mesh" (attached).

  TL;DR: alice@example.com.mm--MBTVK-ZKCWT-KHMTE-XM3I7-GSQNK-MLFYE

The "mm" R-LDH namespace (if/when implemented) or some other future
namespace should probably not be excluded at this time.

If the intent is to canonicalize A-labels to U-labels, then perhaps
only "xn--" labels should be proscribed, if any.

On the other hand, I see there is some support for allowing
certificates to contain whatever form is actually used in email
headers, and perhaps more than just one such form.  If so, there
is no need to proscribe any names at all.  The client performs no
conversions, and the certificate would need to be inclusive of any
addresses that are in actual use.

-- 
	Viktor.
--- Begin Message ---
One of the big problems I have found in trying to argue for ways we can
improve Internet security is that there are two camps. The incrementalists
will only look at solutions that provide an improvement on the status qujo
in one area and the perfectionists insist that any solution that does not
solve every possible problem isn't worth considering.

How about we do both?

Also to save time:

* Yes, I understand the deployment problem very well, I worked with the guy
who solved the network hypertext deployment problem after 20 years of
people failing.
* Yes, everything is end to end secure,
* Yes the transport is also secure to prevent metadata attacks.
* Yes it works with OpenPGP
* Yes it works with S/MIME
* Yes you can use it with SMTP/IMAP/POP
* Yes you can use it with Jabber
* No, you do not have to use a CA
* Yes, you may use a CA where a CA adds value
* Yes, I have considered the lock in problem
* Yes, you can bolt in your own trust model
* REST/HTTPS/JSON.
* AES/RSA/DiffieHelman, moving to CurveX for production.
* Yes it is unencumbered, apart from one part which will unlock this year.
* Yes I have a strategy for QRC
* No, it is not a walled garden
* Yes, you can adapt the system to use escrow cryptography but not without
the parties knowing so this is a frontdoor, not a backdoor.
* My employer sells endpoint protection systems, the Mesh is not a
substitute for endpoint protection, thank you for your interest.
* Reference code runs on Windows, Linux and should run on OSX. It is all
MIT license, so are the protocol compiler tools.

* Yes, it is easy to use. In fact it is exactly as easy to use as the
existing protocols because the user doesn't need to know that they are
doing security
* Yes it is easy to configure.
* Yes, I need help, a lot of help

OK so how is this possible?

First observation is that we now have several protocols that provide users
with end to end security that are really easy to use. The only real problem
I have with those systems is that they operate inside walled gardens. They
are not going to be a replacement for email.

Second is that public key cryptography is now cheap in terms of both cost
and performance. We couldn't do very interesting crypto in the 90s because
machines bogged


There are three contributions made by the Mathematical Mesh:

1) An infrastructure for managing and using client keypairs.

Adding cryptography to a protocol is actually quite easy when both parties
have public keypairs. So if we have an infrastructure that allows a user to
'glue' all their devices together into a personal mesh such that they all
have keypairs provisioned for each cryptographic purpose they might need
them for, cryptography becomes really easy for the user.

2) Extend a direct trust model into the DNS

We all know about TOR and onion routing. Well what if I could have an email
address that included my OpenPGP fingerprint? Well we can. Just use the
xx-- DNS label prefix to mark the fingerprint as not an ICANN DNS labnel
and we can make the fingerprint the TLD:

alice@example.com.mm--MBTVK-ZKCWT-KHMTE-XM3I7-GSQNK-MLFYE

This means, 'only send mail to this address in compliance with a policy
signed under the fingerprint MBTVK...' Said policy could be an OpenPGP key
or it could be a Mesh mail profile.

3) Use of Proxy Re-Encryption (Recryption)

HTTPS provides end to end encryption between the user's client and the web
site serving the content. Using Proxy Re-Encryption we can provide end to
end encryption between the content creator and the user's client. This is
the part of the system that will be locked until late this year, (not that
I am sure the patent is valid, why bother checking when it expires)

We all know that two key cryptography is better than one. It is better
because encryption and decryption are different functions and using
separate keys for separate functions allows these to be done by different
parties. Recryption is three key cryptography and it is better than two key
for the same exact reason.

Using recryption allows us to develop protocols in which Alice is able to
publish a single encryption key but read her email on three different
devices, each of which has a separate decryption key so that she can
mitigate the risk if one of the devices is lost.


Job one is making it easy to manage client side keys.

Once we have that infrastructure, all else becomes straightforward. My
original goal with the Mesh was to make it easy to configure S/MIME and
OpenPGP. David Clark asked me to add SSH which I immediately realized could
be the killer app because the big problem with configuring SSH is that if
you do it to a machine at a remote site, 1000 miles away and you screw up,
someone has to get on a plane to fix it.

However, any infrastructure that allows mail application to say 'here are
the encryption keys to use to send mail to me and when to use them' can
also say 'I accept JSON format nextgen mail'. So this is an infrastructure
that allows us to lock down the legacy email systems as best as can be
managed but also eliminates the biggest barrier to deployment of a
successor system.


I am looking for help to make this happen.

http://prismproof.org/
--- End Message ---