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, 01 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 ---
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Alexey Melnikov
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Patrik Fältström
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Patrik Fältström
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John Levine
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Patrik Fältström
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John R Levine
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John Levine
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John Levine
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Diversity, writing systems, identifiers, and prot… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John R. Levine
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Stephen Farrell
- RE: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Jim Schaad
- RE: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Stephen Farrell
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Wei Chuang
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Viktor Dukhovni
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Wei Chuang
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Viktor Dukhovni
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… tom p.
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Wei Chuang
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Wei Chuang